Laurent Almeras created WICKET-7186:
---------------------------------------
Summary: 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.1, 10.9.0
Reporter: Laurent Almeras
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)
