[shrinkwrap-issues] [JBoss JIRA] (SHRINKRES-86) Rework export mechanism

[Karel Piwko (JIRA)]

    [ https://issues.jboss.org/browse/SHRINKRES-86?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12733443#comment-12733443 ] 

Karel Piwko commented on SHRINKRES-86:
--------------------------------------

That would be really helpful. There are definitely race conditions which often lead to a deadlock. With both Zip and Tar implementations.
                
> Rework export mechanism
> -----------------------
>
>                 Key: SHRINKRES-86
>                 URL: https://issues.jboss.org/browse/SHRINKRES-86
>             Project: ShrinkWrap Resolvers
>          Issue Type: Task
>            Reporter: Michal Matloka
>            Assignee: Michal Matloka
>
> Based on talk with Andrew Rubinger:
> 20:06:17 - ALR: I'd like to rework the ShrinkWrap export mechanism
> 20:06:28 - ALR: Currently it's a multi-threaded design
> 20:07:04 - ALR: This is so that we don't have to hold the entire contents in memory to return the InputStream
> 20:07:15 - ALR: It works by using piped streams 
> 20:07:33 - ALR: The JDK ZipOutputStream to write out to a pipe, then an InputStream which reads into it.
> 20:07:38 - ALR: This gives a "pull" model
> 20:07:55 - ALR: As the user reads in from the instream, this permits the outstream to fill the buffer
> 20:08:00 - ALR: Only the buffer is held in-memory
> 20:08:04 - ALR: What I want to do:
> 20:08:24 - ALR: Make a ZipInputStream which can directly read an archive 
> 20:08:32 - ALR: So we bypass the piping and the need for Threads
> 20:08:52 - ALR: (JDK ZipInputStream only reads in current ZIP formats)
> 20:09:12 - ALR: THIS new ZipInputStream we would need to encode as ZIP as "read" is called
> 20:09:18 - ALR: Keeping the pull model intact

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira