You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@pdfbox.apache.org by "Andreas Lehmkühler (JIRA)" <ji...@apache.org> on 2015/07/15 13:17:05 UTC

[jira] [Commented] (PDFBOX-2883) Unify memory handling

    [ https://issues.apache.org/jira/browse/PDFBOX-2883?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14627902#comment-14627902 ] 

Andreas Lehmkühler commented on PDFBOX-2883:
--------------------------------------------

Just before starting the discussion I'd like to clarify one point:
{quote}
PDFBOX now has at least 2 different mechanisms to use main memory vs. keeping large data in temporary file: in case of provided input stream the stream is copied to temporary file and all read PDF streams are handled by RandomAccessBuffer/ScratchFile.
{quote}
That's not correct. After streamlining the whole fpdf source handling there is only one mechanism left. The user has to decide wether to use memory or scratch file based buffering. That is true for internal buffers as well as for the copy of the input stream.

> Unify memory handling
> ---------------------
>
>                 Key: PDFBOX-2883
>                 URL: https://issues.apache.org/jira/browse/PDFBOX-2883
>             Project: PDFBox
>          Issue Type: Improvement
>          Components: Parsing
>    Affects Versions: 2.0.0
>            Reporter: Timo Boehme
>            Assignee: Timo Boehme
>
> PDFBOX now has at least 2 different mechanisms to use main memory vs. keeping large data in temporary file: in case of provided input stream the stream is copied to temporary file and all read PDF streams are handled by RandomAccessBuffer/ScratchFile.
> In PDFBOX-2882 I've done a re-implementation for ScratchFile which is quite fast and allows to set a maximum amount of memory to be used for its pages before it starts using the scratch file. This implementation could be used as the general 'backend' for all buffered streams and even the file input stream copy. As long as the PDF fits into the allowed maximum memory it should equally fast as RandomAccessBuffer while it allows for good control of memory usage by going to scratch file if needed. This prevents OOM in case of large files.
> In order to use this the PDDocument methods should be changed to not have a 'useScratchFile' parameter but to take a MemoryHandling object which details the Buffering strategy (using ScratchFile; what amount of main memory can be used, ...).
> I've opened this issue for discussing. Since we need API changes in PDDocument it should be done before 2.0 release.



--
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