[
https://issues.apache.org/jira/browse/FILEUPLOAD-368?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18073704#comment-18073704
]
Bruno Antunes commented on FILEUPLOAD-368:
------------------------------------------
For reference, I also tested this with ** Commons FileUpload 1.6.1-SNAPSHOT
(20260410.123442-14).
The observed behavior is consistent with ** 1.6.0:
* When the {{InputStream}} returned by {{FileItem.getInputStream()}} is not
explicitly closed:
** Temporary files are unlinked after GC
** File descriptors remain open and appear as {{(deleted)}} in {{lsof +L1}}
* When the stream is explicitly closed:
** No descriptor retention is observed
This suggests the behavior has not changed in the current snapshot.
> 1.6.0 unlike 1.5: brought on an issue where temporary files and descriptors
> were not being freed
> -------------------------------------------------------------------------------------------------
>
> Key: FILEUPLOAD-368
> URL: https://issues.apache.org/jira/browse/FILEUPLOAD-368
> Project: Commons FileUpload
> Issue Type: Bug
> Affects Versions: 1.6.0
> Reporter: David Campbell
> Priority: Major
> Attachments: image-2025-12-02-13-22-04-101.png,
> image-2025-12-02-13-24-56-498.png
>
>
> An upgrade of commons-fileupload from 1.5 to 1.6.0 brought on a problem on
> high-load servers where uploaded files were not being deleted and the server
> file descriptor utilisation kept growing. On all server instances, file
> resource utilisation kept growing to the point where it was filling /tmp
> completely and then the server instances needed restarting to solve, as file
> space is not reclaimed even on file deletion on Unix servers when file
> descriptors are still open. The same issue occurred on all our server
> instances.
> We had a major production incident as a result.
> Rolled back to 1.5. That fixed the issue, problem completely gone.
> Don't know any further details of the whys at this point.
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
