[ https://issues.apache.org/jira/browse/PDFBOX-5068?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17260305#comment-17260305 ]
Ralf Hauser commented on PDFBOX-5068: ------------------------------------- Just for reference, did a test with [^minimum.pdf] . It still creates a correctly signed pdf with -Xmx as low as {color:#de350b}_*12*_{color}m . Conclusion: albeit theoretically probably reachable, pdfbox is a long way away from "constant memory signing" > OutOfMemory while signing large documents - continued > ----------------------------------------------------- > > Key: PDFBOX-5068 > URL: https://issues.apache.org/jira/browse/PDFBOX-5068 > Project: PDFBox > Issue Type: Improvement > Components: Signing > Affects Versions: 2.0.23 > Reporter: Ralf Hauser > Priority: Major > Attachments: RandomAccessReadBufferDiag.java, minimum.pdf > > > Continuation of PDFBOX-2512 > > in COSWriter.prepareIncrement(), for the test case > cosDoc.getXrefTable().keySet() has size 5925. For each of thes keys, > cosDoc.getObjectFromPool() gets an object that is not just referencing some > part of the input document, but duplicates it (which is unavoidable in the > case where they are decompressed with FlateFilter - albeit this could > possibly be done "lazy") > -Xmx20m 746/5925 > -Xmx25m 1615/5925 > -Xmx30m 2800/5925 > -Xmx40m 3872/5925 > -Xmx55m 5773/5925 > With 60m, it gets them all, but dies later with less telling > java.lang.OutOfMemoryError: GC overhead limit exceeded > > This assumes the patch of PDFBOX-5067 already in place - or using > CreateVisibleSignature2.java as starting point -- This message was sent by Atlassian Jira (v8.3.4#803005) --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org