[
https://issues.apache.org/jira/browse/PDFBOX-2999?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14934833#comment-14934833
]
Timo Boehme commented on PDFBOX-2999:
-------------------------------------
As I understand it the normal way of using {{COSStream}} is to create an
instance, than get an output stream to write data and afterwards get one or
multiple input streams to read the data. In this scenario the first buffer
which was already created by the constructor is thrown away by the
getOutputStream methods (without being used and without being closed).
Second when {{getOUtputStream()}} creates a new randomAccess buffer the old one
is not closed. It cannot be closed by input streams created on it and it cannot
be closed by the output streams created on it. However this is only a problem
if there will be multiple calls to {{getOutputStream()}} - maybe this should be
forbidden?
> 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-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org
