commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Plamen Totev (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (COMPRESS-375) Allow the clients of ParallelScatterZipCreator to provide ZipArchiveEntryRequestSupplier
Date Wed, 30 Nov 2016 19:07:59 GMT

     [ https://issues.apache.org/jira/browse/COMPRESS-375?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Plamen Totev updated COMPRESS-375:
----------------------------------
    Description: 
Currently clients of {{ParallelScatterZipCreator}} could provide {{ZipArchiveEntry}} and {{InputStreamSupplier}}
through {{ParallelScatterZipCreator#addArchiveEntry}}. From those two a {{ZipArchiveEntryRequest}}
is created. Providing {{InputStreamSupplier}} solves the problem with opening too many files
- streams are opened just-in-time - when an entry is  compressed, not when it's submitted.

But there are use cases when the stream may contain information about the {{ZipArchiveEntry}}.
In those cases creating {{ZipArchiveEntry}} before the {{InputStream}} is opened won't work.
If there is an option to supply both {{ZipArchiveEntry}} and {{InputStreamSupplier}} ({{ZipArchiveEntryRequest}}),
this will solve the issue.

There is a bug in Plexus Archiver (https://github.com/codehaus-plexus/plexus-archiver/issues/53)
that is example for such use case. Plexus Archiver have option that allows entries that are
already zip files to be stored instead of compressed ({{AbstractZipArchiver.recompressAddedZips}}).
To detect if given entry is zip archive, {{AbstractZipArchiver}} should read the first several
bytes of the stream. So creating {{ZipArchiveEntry}} before the stream is opened is not useful
- the compress mode is not known. Opening the stream when the  {{ZipArchiveEntry}} is created
won't work either. Because you can add entries to {{ParallelScatterZipCreator}} a lot faster
than you could compress them you could open too many files very fast. And I don't think opening
and closing the stream is an option as such operations could be relatively expensive in the
general case. But if it could supply both the {{ZipArchiveEntry}} and the {{InputStream}}
just-in-time (by passing {{ZipArchiveEntryRequestSupplier}} to {{ParallelScatterZipCreator}})
then the problem is solved.

What do you think? Does the addition of {{ParallelScatterZipCreator#addArchiveEntry(ZipArchiveEntryRequestSupplier)}}
make sense?

  was:
Currently clients of {{ParallelScatterZipCreator}} could provide {{ZipArchiveEntry}} and {{InputStreamSupplier}}
through {{ParallelScatterZipCreator#addArchiveEntry}}. From those two a {{ZipArchiveEntryRequest}}
is created. Providing {{InputStreamSupplier}} solves the problem with opening too many files
- streams are opened just-in-time - when an entry is  compressed, not when it's submitted.

But there are use cases when the stream may contain information about the {{ZipArchiveEntry}}.
In those cases creating {{ZipArchiveEntry}} before the {{InputStream}} is opened won't work.
If there is an option to supply both {{ZipArchiveEntry}} and {{InputStreamSupplier}} ({{ZipArchiveEntryRequest}}),
this will solve the issue.

There is a bug in Plexus Archiver (https://github.com/codehaus-plexus/plexus-archiver/issues/53)
that is example for such use case. Plexus Archiver have option that allows entries that are
already zip files to be stored instead of compressed ({{AbstractZipArchiver.recompressAddedZips}}).
To detect if given entry is zip archive, {{AbstractZipArchiver}} should read the first several
bytes of the stream. So creating {{ZipArchiveEntry}} before the stream is opened is not useful
- the compress mode is not known. Opening the stream when the  {{ZipArchiveEntry}} is created
won't work either. Because you can add entries to {{ParallelScatterZipCreator}} a lot faster
than you could compress them you could open too many files very fast. And I don't think opening
and closing the stream is an option as such operations could be relatively expensive in the
general case. But if it could supply both the {{ZipArchiveEntry}} and the {{InputStream}}
just-in-time (by passing {{ZipArchiveEntryRequestSupplier}} to {{ParallelScatterZipCreator}})
then the problem is solved.

What do you think. Does the addition of {{ParallelScatterZipCreator#addArchiveEntry(ZipArchiveEntryRequestSupplier)}}
make sense?


> Allow the clients of ParallelScatterZipCreator to provide ZipArchiveEntryRequestSupplier
> ----------------------------------------------------------------------------------------
>
>                 Key: COMPRESS-375
>                 URL: https://issues.apache.org/jira/browse/COMPRESS-375
>             Project: Commons Compress
>          Issue Type: Improvement
>          Components: Archivers
>            Reporter: Plamen Totev
>
> Currently clients of {{ParallelScatterZipCreator}} could provide {{ZipArchiveEntry}}
and {{InputStreamSupplier}} through {{ParallelScatterZipCreator#addArchiveEntry}}. From those
two a {{ZipArchiveEntryRequest}} is created. Providing {{InputStreamSupplier}} solves the
problem with opening too many files - streams are opened just-in-time - when an entry is 
compressed, not when it's submitted.
> But there are use cases when the stream may contain information about the {{ZipArchiveEntry}}.
In those cases creating {{ZipArchiveEntry}} before the {{InputStream}} is opened won't work.
If there is an option to supply both {{ZipArchiveEntry}} and {{InputStreamSupplier}} ({{ZipArchiveEntryRequest}}),
this will solve the issue.
> There is a bug in Plexus Archiver (https://github.com/codehaus-plexus/plexus-archiver/issues/53)
that is example for such use case. Plexus Archiver have option that allows entries that are
already zip files to be stored instead of compressed ({{AbstractZipArchiver.recompressAddedZips}}).
To detect if given entry is zip archive, {{AbstractZipArchiver}} should read the first several
bytes of the stream. So creating {{ZipArchiveEntry}} before the stream is opened is not useful
- the compress mode is not known. Opening the stream when the  {{ZipArchiveEntry}} is created
won't work either. Because you can add entries to {{ParallelScatterZipCreator}} a lot faster
than you could compress them you could open too many files very fast. And I don't think opening
and closing the stream is an option as such operations could be relatively expensive in the
general case. But if it could supply both the {{ZipArchiveEntry}} and the {{InputStream}}
just-in-time (by passing {{ZipArchiveEntryRequestSupplier}} to {{ParallelScatterZipCreator}})
then the problem is solved.
> What do you think? Does the addition of {{ParallelScatterZipCreator#addArchiveEntry(ZipArchiveEntryRequestSupplier)}}
make sense?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message