[
https://issues.apache.org/jira/browse/PDFBOX-3730?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15939091#comment-15939091
]
Peter Pinnau commented on PDFBOX-3730:
--------------------------------------
I understand. Without buffering save(OutputStream) offers most flexibility. I
just wondered that PDDocument.load(InputStream) includes buffering and save()
doesn't.
For the documentation I would propose a clearer text like "it is recommended to
wrap your outputStream to BufferedOutputStream".
In my case saving worked without any problems for about 2 years. Local files,
SMB share in the same LAN - no problem. Whe are now deploying the software in
an
environment where SMB share is connected via VPN site-to-site tunnel.
Saving of a small PDF took up to 3 minutes. With BufferdOutputStream 3 seconds.
> Encapsulate outputStream into BufferedOutputStream in PDDocument.save()
> -----------------------------------------------------------------------
>
> Key: PDFBOX-3730
> URL: https://issues.apache.org/jira/browse/PDFBOX-3730
> Project: PDFBox
> Issue Type: Improvement
> Components: Writing
> Affects Versions: 2.0.5
> Reporter: Peter Pinnau
> Priority: Minor
> Fix For: 2.0.6, 2.1.0
>
>
> I recognized very slow performance of PDDocument.save() with a
> FileOutputStream over a VPN connection.
> I did some testing and found out that using PDDocument.save(File file) solved
> the issue. So the BufferedInputStream makes the difference.
> Since my document API uses streams I encapsulate the OutputStream in a
> BufferedOutputStream if neccessary:
> if (!(outputStream instanceof BufferedOutputStream)) {
> outputStream = new BufferedOutputStream(outputStream);
> }
> pdDocument.save(outputStream);
> PDDocument.load() already does that with the InputStream. So I wonder if that
> would be an improvement for save(), too?
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
