[
https://issues.apache.org/jira/browse/COMPRESS-485?focusedWorklogId=291070&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-291070
]
ASF GitHub Bot logged work on COMPRESS-485:
-------------------------------------------
Author: ASF GitHub Bot
Created on: 08/Aug/19 08:32
Start Date: 08/Aug/19 08:32
Worklog Time Spent: 10m
Work Description: Tibor17 commented on issue #79: Pull/78 COMPRESS-485 +
Substituting 'synchronized' with faster and fully thread-safe collections
'ConcurrentLinkedDeque' and iterators.
URL: https://github.com/apache/commons-compress/pull/79#issuecomment-519423686
@bodewig
You have opened two things, but sorry I have to say, they are not related
and here is my explanation why:
1. locking within private/public methods
2. synchronized iterators
Since now, I am refering to before #78 .
Regarding (1) you mentioned:
> synchronized would ensure you couldn't spin off new threads and add
entries to them while writing or closing
The methods (`addArchiveEntry` and `submit`) and `writeTo` were not mutually
exclusive.
If we want to exclusive then we should fire another PR for that.
If you want to prevent `writeTo` from double/parallel call, we can do this
`if (es.isShutdown()) throw ...Exception`.
Locking all 3 methods can be done with `AtomicBoolean` but that needs to see
example.
Regarding (2):
It is old style to use collections wrapped in `synchronizedList()` and use
iterators wrapped within `synchronized (streams) {}`. In modern collections
`ConcurrentLinkedDequeue` is beneficial because it does not require any
external locking.
There was also one issue because the variable `futures` was not synchronized
collection.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
[email protected]
Issue Time Tracking
-------------------
Worklog Id: (was: 291070)
Time Spent: 3h 20m (was: 3h 10m)
> Reproducible Builds: keep entries order when gathering ScatterZipOutputStream
> content in ParallelScatterZipCreator
> ------------------------------------------------------------------------------------------------------------------
>
> Key: COMPRESS-485
> URL: https://issues.apache.org/jira/browse/COMPRESS-485
> Project: Commons Compress
> Issue Type: Improvement
> Components: Archivers
> Affects Versions: 1.18
> Reporter: Hervé Boutemy
> Priority: Major
> Fix For: 1.19
>
> Time Spent: 3h 20m
> Remaining Estimate: 0h
>
> currently, zip files created using ParallelScatterZipCreator have random
> order.
> This is causing issues when trying to do Reproducible Builds with Maven
> MNG-6276
> Studying ParallelScatterZipCreator, entries are kept sorted in memory in
> futures list: instead of writing each full scatter in sequence, iterating
> over futures should permit to write each zip entry in original order, without
> changing the API or any performance of the gathering process
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
