[jira] [Commented] (COMPRESS-618) Make ZipFile thread safe

["Luís Filipe Nassif (Jira)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/COMPRESS-618?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17524315#comment-17524315 ] 

Luís Filipe Nassif commented on COMPRESS-618:
---------------------------------------------

Please also check this: [https://github.com/sepinf-inc/IPED/issues/1068]

 

Synchronization on ZipFile.getInputStream(ze) only works with splitted archives and ignoreLocalFileHeader == true if the ZipSplitReadOnlySeekableByteChannel passed to constructor is used as lock, otherwise reading the returned input streams concurrently with other calls to getInputStream() results in concurrency issues.

> Make ZipFile thread safe
> ------------------------
>
>                 Key: COMPRESS-618
>                 URL: https://issues.apache.org/jira/browse/COMPRESS-618
>             Project: Commons Compress
>          Issue Type: Improvement
>          Components: Archivers
>    Affects Versions: 1.21
>            Reporter: Luís Filipe Nassif
>            Priority: Major
>
> Sorry if another issue already exists for this, I couldn't find one. When I enable the ignoreLocalFileHeader constructor flag, I started to get BufferOverflowException/BufferUnderFlowException while calling ZipFile.getInputStream(ZipArchiveEntry). Looking at the code, there is some local instances of byte[] and ByteBuffer reused by some private methods that should be the cause of those exceptions. Everything seems fine if ignoreLocalFileHeader is false, but I need to open very large zip files as fast as possible. If I synchronize on ZipFile.getInputStream(ze), it seems to workaround. Actually, I don't know if ZipFile was designed to be thread safe, but it would be nice to be. I also saw some synchronization code in BoundedSeekableByteChannelInputStream class, so not sure if this issue is an enhancement or bug report...



--
This message was sent by Atlassian Jira
(v8.20.7#820007)