[
https://issues.apache.org/jira/browse/COMPRESS-470?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Bodewig resolved COMPRESS-470.
-------------------------------------
Resolution: Fixed
Fix Version/s: 1.19
I've added code that ensures the streams get closed - and that extra effort is
spent on getting rid temporary files.
The later won't help with your case of very long running processes, for those
something like the implementation you've shared in
https://issues.apache.org/jira/browse/COMPRESS-446?focusedCommentId=16684043&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16684043
is the better option. Many thanks for that!
> ParallelScatterZipCreator leaks temporary files (and maybe more)
> ----------------------------------------------------------------
>
> Key: COMPRESS-470
> URL: https://issues.apache.org/jira/browse/COMPRESS-470
> Project: Commons Compress
> Issue Type: Bug
> Components: Archivers
> Affects Versions: 1.18
> Reporter: Stefan Bodewig
> Priority: Major
> Fix For: 1.19
>
>
> As indicated by
> https://issues.apache.org/jira/browse/COMPRESS-446?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16679878#comment-16679878
> COMPRESS-446 may have closed one resource leak but not all of them.
> If an exception occurs in {{writeTo}} we may miss calling {{close}} on some
> of the {{ScatterZipOutputStream}}s which in turn may leak resources like
> temporary files opened by using {{FileBasedScatterGatherBackingStore}}.
> This affects all versions since 1.10
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
