[
https://issues.apache.org/jira/browse/WICKET-7186?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18088296#comment-18088296
]
ASF subversion and git services commented on WICKET-7186:
---------------------------------------------------------
Commit 36b334d58bd024e4fc39dc0f96610638a5001379 in wicket's branch
refs/heads/master from Laurent
[ https://gitbox.apache.org/repos/asf?p=wicket.git;h=36b334d58b ]
WICKET-7186: correctly delegate calls to wicket cleaner (#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.
> 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)
