eclipse-ee4j / jersey

Eclipse Jersey Project - Read our Wiki:
https://github.com/eclipse-ee4j/jersey/wiki
Other
692 stars 353 forks source link

memory leak in multipart uploads #3259

Open jerseyrobot opened 9 years ago

jerseyrobot commented 9 years ago

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]

jerseyrobot commented 6 years ago
jerseyrobot commented 9 years ago

@glassfishrobot Commented Reported by phraktle2

jerseyrobot commented 8 years ago

@glassfishrobot Commented phraktle2 said: Any plans on fixing this? This affects long running server-apps, resulting in OOM.

jerseyrobot commented 7 years ago

@glassfishrobot Commented phraktle2 said: This is still a problem.

jerseyrobot commented 7 years ago

@glassfishrobot Commented This issue was imported from java.net JIRA JERSEY-2987

gopi-gith commented 6 years ago

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?

essobedo commented 4 years ago

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.

averigin commented 3 years ago

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().

averigin commented 2 years ago

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.