[
https://issues.apache.org/jira/browse/WICKET-7186?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18088216#comment-18088216
]
ASF GitHub Bot commented on WICKET-7186:
----------------------------------------
lalmeras opened a new pull request, #1485:
URL: https://github.com/apache/wicket/pull/1485
FileCleaningTrackerAdapter does not delegate some calls to IFileCleaner.
These call are then performed by FileCleaningTracker superclass. Each
FileCleaningTrackerAdapter then create a Reaper thread that is leaked
(FileCleaningTrackerAdapter is request-scope).
Intended behavior is to delegate to IFileCleaner that is a singleton (there
is at most 1 Reaper by wicket application).
The issue appears on wicket 10.9.x as commons-fileupload2-M5 refactors
DiskFileItem and now calls the Path variant of track(...) method.
This fix adds the missing delegate methods.
---
I successfully tested this fix on wicket-10.x branch with one of our
application and a breakpoint on `FileCleaningTracker$Reaper`. Before fix, one
Reaper is created for each file upload. After fix, Reaper is created only on
the first call.
> wicket 10.9.0 / 10.9.1 leaks File Reaper threads
> ------------------------------------------------
>
> Key: WICKET-7186
> URL: https://issues.apache.org/jira/browse/WICKET-7186
> Project: Wicket
> Issue Type: Bug
> Components: wicket-core
> Affects Versions: 10.9.0, 10.9.1
> Reporter: Laurent Almeras
> Priority: Critical
>
> Wicket 10.9.0 and 10.9.1 leaks File Reaper threads.
> One of our application leaks "File Reaper" 4.000 threads / day. The issue can
> be tracked with `jstack JAVA_PID | grep "File Reaper" | wc -l` to count
> current "File Reaper" threads. Java heap histogram can also be used to count
> org.apache.wicket.util.file.FileCleanerTrackerAdapter or
> org.apache.commons.io.FileCleaningTracker$Reaper (I find 1 instance by File
> Reaper thread).
> Thread leak can trigger resource exhaustion (process by user, memory). For
> our case, application no longer create new threads, and it finally become
> inaccessible as it remains no valid AJP worker for requests.
> I think the bug is located in `FileCleanerTrackerAdapter` as I have as many
> instance as File Reaper thread:
> * FileCleanerTrackerAdapter extends FileCleaningTracker from
> commons-fileupload2
> * It is intended to work as a delegate for IFileClean ; 4 track(...) methods
> are overriden
> * But FileCleaningTracker has 6 track(...) methods ; methods accepting Path
> objects are not overriden
> * `DiskFileItem` from commons-fileupload2 2.0.0-M5 was refactored. Call
> graph is no longer the same, but the only track(...) call is modified from
> File variant to Path variant
> * So earch upload managed by wicket + commons-fileupload2 no longer
> delegates call to IFileCleaner (this instance is a singleton by wicket
> application) but calls FileCleanerTrackerAdapter : it's singleton by request,
> and it triggers it creates its own
> org.apache.commons.io.FileCleaningTracker$Reaper
> With a breakpoint on `org.apache.commons.io.FileCleaningTracker$Reaper`, it
> is easy to observe that each upload builds a new Reaper.
> I suppose the fix is to add the missing `track(...)` methods in
> FileCleanerTrackerAdapter so that call are correctly delegated to
> IFileCleaner.
> Issue is important as soon as your web-application manages a lot of file
> upload. Application restart is needed to avoid resource exhaustion.
> Change dependency for commons-fileupload2 2.0.0-M4 is not a valid workaround
> as there is incompatible API change in wicket
> (JakartaServletFileUpload.setMaxSize is needed and not available)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
