[prev in list] [next in list] [prev in thread] [next in thread] 

List:       jakarta-commons-dev
Subject:    [jira] [Commented] (COMPRESS-446) Resource Leak in ParallelScatterZipCreator#writeTo(ZipArchiveOutpu
From:       "Gary Gregory (JIRA)" <jira () apache ! org>
Date:       2018-03-31 12:58:00
Message-ID: JIRA.13145982.1521318240000.155043.1522501080408 () Atlassian ! JIRA
[Download RAW message or body]


    [ https://issues.apache.org/jira/browse/COMPRESS-446?page=com.atlassian.jira.plugi \
n.system.issuetabpanels:comment-tabpanel&focusedCommentId=16421319#comment-16421319 ] \


Gary Gregory commented on COMPRESS-446:
---------------------------------------

I suppose you are correct, not as bad as I initially thought.

> Resource Leak in ParallelScatterZipCreator#writeTo(ZipArchiveOutputStream)
> --------------------------------------------------------------------------
> 
> Key: COMPRESS-446
> URL: https://issues.apache.org/jira/browse/COMPRESS-446
> Project: Commons Compress
> Issue Type: Bug
> Components: Archivers
> Affects Versions: 1.16.1
> Environment: The application was running inside a Docker container, the JVM had \
>                 about 1.7 GByte heap space.
> Reporter: Christoph Ludwig
> Priority: Major
> Fix For: 1.17
> 
> 
> Before it does anything else, \
> {{ParallelScatterZipCreator#writeTo(ZipArchiveOutputStream)}} loops over all \
> futures returned by the creator`s executor service and calls {{Future#get()}}. This \
> will block until the future's computation is completed, respectively - i.e., until \
> all entries have been written to the thread-local scatter streams. However, if the \
> computation of a future fails, then {{Future#get()}} can also throw an exception. \
> This exception escapes \
> {{ParallelScatterZipCreator#writeTo(ZipArchiveOutputStream)}} before the executor \
> service is shut down. The latter means that also the thread-local variables in the \
> executor service's threads and all objects referenced by them continue to exist and \
> cannot be reclaimed by the GC. I encountered this situation when - while processing \
> an archive with 130,000 documents - the JVM threw an {{OutOfMemoryError}}. The \
> application was not able to recover from this OOM error because most of the heap \
> was occupied by objects reachable from the executor service's threads. Of course, \
> the OOM is mostly the fault of my own code; I will be able to work around the \
> "leaked" executor service because I supply it in the first place and can therefore \
> shut it down if I detect an error situation.   The effect would be the same, \
> though, if, say, {{Future#get()}} throws an {{InterruptedException}}. Therefore, \
> {{ParallelScatterZipCreator#writeTo(ZipArchiveOutputStream)}}  should either shut \
> down and release all resources if it cannot complete its task due to an Exception \
> thrown by a future or it should offer a reasonable recovery strategy. 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[prev in list] [next in list] [prev in thread] [next in thread]