[jira] [Created] (WICKET-7186) wicket 10.9.0 / 10.9.1 leaks File Reaper threads

["Laurent Almeras (Jira)" <ji...@apache.org>]

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)