COMPRESS-485 keep zip entries order in parallel zip creation#78
COMPRESS-485 keep zip entries order in parallel zip creation#78hboutemy wants to merge 1 commit intoapache:masterfrom
Conversation
hboutemy
force-pushed
the
COMPRESS-485
branch
3 times, most recently
from
b3a1b0a to
dc89094
Compare
this will ease Reproducible Builds when creating zip or jar archives thanks to Arnaud Nauwynck for the great help
|
|
||
| synchronized (streams) { | ||
| // write zip entries in the order they were added (kept as futures) | ||
| for (final Future<ScatterZipOutputStream> future : futures) { |
There was a problem hiding this comment.
This loop was added. And it is a problem in this synchronized block.
The monitor lock is streams and not futures. They cannot be both in one statement.
Problem: this will cause NPE when the CPU is overloaded. The same issue was fixed in Surefire (see memory model).
Additionally the futures.add() is not synchronized!
One way would be for you to introduce double synchro block.
I would not do it! Instead I would avoid synchronizations of ArrayList and on both. Then I would use modern collections which do not need external synchronizatrions (i.e. Collections.synch...) and this way there would not be any synchronized. Use ConcurrentLinkedDequeue. It is useful when you add to the tail of the queue and do not remove, and if you iterate, because this implementation safely iterates even if you change it : no issue.
There was a problem hiding this comment.
please provide a PR, my branch is https://github.com/hboutemy/commons-compress/tree/COMPRESS-485
|
I am fine with the change, Hervé explained in great detail in the JIRA issue his approach. |
|
Thanks @hboutemy and sorry that it took us so long. See my comments in https://issues.apache.org/jira/browse/COMPRESS-485?focusedCommentId=16902075&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16902075 This PR has now been merged. |
|
@bodewig |
|
I have a bunch of issues assigned to the 1.19 milestone in JIRA and intend to cut a new release once all of them are fixed. This doesn't imply they'd be the only issues acceptable, but these are the only ones I can promise I will work on. |
5 participants
this will enable Reproducible Builds when creating zip or jar archives
this is another implementation of idea in PR #77