You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@commons.apache.org by GitBox <gi...@apache.org> on 2020/02/02 13:27:59 UTC

[GitHub] [commons-compress] bodewig commented on issue #90: Compress-477 : add zip64 support for split zip

bodewig commented on issue #90: Compress-477 : add zip64 support for split zip
URL: https://github.com/apache/commons-compress/pull/90#issuecomment-581135612
 
 
   This is not really a new issue introduced with the split zips feature, `MultiReadOnlySeekableByteChannel` has been keeping channels open before as well.
   
   Honestly I haven't got any idea of how much "jumping around" reading split archives (zip or 7z) actually involves. In both cases we read the channels containing file meta data once and will likely never go back to them. So a small number of open channels may be sufficient. OTOH I expect most split archives to only have a pretty small number of parts, an archive with more than 100 parts is something that I don't expect to be common. Therefore making sure we don't open too many streams is probably not that important at all.
   
   I realize I'm not answering your question :-)
   
   I'd make the number of simultaneously opened streams configurable. "infinite" might even be a good default so that people only need to deal with it explicitly if they run into trouble. But in real life situations I'd expect any number bigger than say 20 to have the same effect as infinity (i.e. all channels are open as there are no more than 20 channels anyway).

----------------------------------------------------------------
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:
users@infra.apache.org


With regards,
Apache Git Services