It was fixed in mimepull-1.8.
3 Changes were made in the patch to improve MIMEPULL implicit clean up mechanism:
When the tmp file is created, added tempFile.deleteOnExit() to request the file be deleted when the virtual machine terminates. This will remove the tmp file uopn normal server shutdown even the cleanup mechanism doesn't kick in for it yet.
2) WeakDataFile. drainRefQueueBounded()
Instead of MAX_ITERATIONS of 2, close all the WeakDataFile in the queue to prevent potential disastrous result when under heavy load.
Added org.jvnet.mimepull.CleanUpExecutorFactory, which uses service factory pattern. MIMEPULL when initialized, will search for CleanUpExecutorFactory first in system property and then in META-INF/services. If located, it will uses the executor from the implementation class to monitor and clean up the queue, instead of using WeakDataFile constructor to call drainRefQueueBounded(). This will overcome the drawback that MIMEPULL will always leave uncleaned WeakDataFile in the system since the clean up doesn't start until the next WeakDataFile construction.
MIMEPULL itself contains only the hook, without any CleanUpExecutorFactory implementation. So normal usage will experience the exact same behavior.