You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@pdfbox.apache.org by "John Hewson (JIRA)" <ji...@apache.org> on 2015/09/29 01:26:04 UTC
[jira] [Comment Edited] (PDFBOX-2999) Optimize COSStream scratch
file usage
[ https://issues.apache.org/jira/browse/PDFBOX-2999?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14934324#comment-14934324 ]
John Hewson edited comment on PDFBOX-2999 at 9/28/15 11:25 PM:
---------------------------------------------------------------
I wrote this code very recently, prior to that, COSStream was a giant mess. Please discuss far-reaching changes such as this before making them. Leave the JIRA issue open for a day before committing code so that others get a chance to see it. Consider attaching a patch and asking for others to look at it.
Why have you deferred the creation of this.randomAccess? What benefit does this bring?
{quote}
- requesting an input stream without an corresponding output stream being created before is not allowed (throw some kind of exception)
{quote}
That's just an empty stream and it's perfectly legal.
{quote}
- when a new output stream is requested, the previous randomAccess buffer will be closed (which means any input stream being created on it must not be accessed anymore - an IOException will be thrown otherwise)
{quote}
It's not possible to create multiple output streams, we already check for that case and throw an exception ("Cannot have more than one open stream writer."). The previous randomAccess buffer will _not_ be closed. However it is possible to have an existing input stream and then create an output stream, which we should probably disallow, because it doesn't make sense.
was (Author: jahewson):
I wrote this code very recently, prior to that, COSStream was a giant mess. Please discuss far-reaching changes such as this before making them. Leave the JIRA issue open for a day before committing code so that others get a chance to see it. Consider attaching a patch and asking for others to look at it.
Why have you deferred the creation of this.randomAccess? What benefit does this bring?
{quote}
- requesting an input stream without an corresponding output stream being created before is not allowed (throw some kind of exception)
{quote}
That's just an empty stream and it's perfectly legal.
{quote}
- when a new output stream is requested, the previous randomAccess buffer will be closed (which means any input stream being created on it must not be accessed anymore - an IOException will be thrown otherwise)
{quote}
It's not possible to create multiple output streams, we already check for that case and throw an exception ("Cannot have more than one open stream writer."). The previous randomAccess buffer will _not_ be closed.
> Optimize COSStream scratch file usage
> -------------------------------------
>
> Key: PDFBOX-2999
> URL: https://issues.apache.org/jira/browse/PDFBOX-2999
> Project: PDFBox
> Issue Type: Improvement
> Components: PDModel
> Affects Versions: 2.0.0
> Reporter: Timo Boehme
> Assignee: Timo Boehme
>
> The usage of scratch file buffers in COSStreams is quite sloppy. A never filled buffer is created in the beginning and existing buffers are discarded without being closed when a variant of {{createOutputStream}} is called. Furthermore it should be clarified if requesting an input stream without having created an output stream before is ok and if a returned input stream keeps valid after a new output stream is created (which is crucial for proper buffer-closing).
> This issue should resolve some of the shortcomings and document the expected or even required usage of COSStream.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@pdfbox.apache.org
For additional commands, e-mail: dev-help@pdfbox.apache.org