Open jerseyrobot opened 9 years ago
@glassfishrobot Commented Reported by phraktle2
@glassfishrobot Commented phraktle2 said: Any plans on fixing this? This affects long running server-apps, resulting in OOM.
@glassfishrobot Commented phraktle2 said: This is still a problem.
@glassfishrobot Commented This issue was imported from java.net JIRA JERSEY-2987
Due to this bug, we are forced to move away from using MultiPart. We refactored our APIs to use non-multipart requests. Is there a way to upvote this bug?
FYI, this bug seems to be fixed thanks to https://github.com/eclipse-ee4j/metro-mimepull/issues/13 that is included in mimepull 1.9.13
and that is now the version used in the master branch of jersey thanks to this commit https://github.com/eclipse-ee4j/jersey/commit/950ce6ce91bd7aafeabb939c487f72f73e77dc71#diff-600376dffeb79835ede4a0b285078036
However so far there is no release of Jersey that includes this upgrade so If you need a fix, you will have to force the version of mimepull to 1.9.13
in your project which I did and it seems to work well.
It looks like mimepull was updated to 1.9.13 in #4425 which was released as part of v2.31.
However, it still seems that multipart requests with files end up generating delete-on-exit hooks. FormDataParamValueParamProvider$FileProvider
still calls Utils.createTempFile()
, which calls File.deleteOnExit()
.
I finally had time to revisit this.
In my endpoint definition, I switched from using a File
to an InputStream
. From what I can tell in FormDataParamValueParamProvider.java
, this generates a FormDataParamValueProvider
instead of a FileProvider
, so it bypasses the Utils.createTempFile()
call. Thus, my endpoint no longer generates delete-on-exit hooks for every request.
I still think this is a work-around and not a proper solution, but I'm posting it in the hopes that it helps someone else.
Requests with multipart uploads create temp files (MIMExxx.tmp) which are marked for deletion using the JVM hook deleteOnExit. For long-running server processes, this is not appropriate since it leads to a memory leak (tracking of an ever-increasing number of references in a LinkedHashSet in java.io.DeleteOnExitHook).
See related mimepull issue: https://java.net/jira/browse/MIMEPULL-13
Affected Versions
[2.21]