You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@pdfbox.apache.org by "Tilman Hausherr (JIRA)" <ji...@apache.org> on 2018/12/06 09:32:00 UTC

[jira] [Comment Edited] (PDFBOX-4396) Memory leak due to soft reference caching

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

Tilman Hausherr edited comment on PDFBOX-4396 at 12/6/18 9:31 AM:
------------------------------------------------------------------

Can you build from source? If yes, open COSStream.java, and add
{code:java}
IOUtils.closeQuietly(randomAccess);{code}
above
{code:java}
randomAccess = scratchFile.createBuffer();{code}
at two places.

My observations that ramdomAccess was not null when an encrypted file is opened, because the same COSStream is rewritten and it can't be closed before that because this would result in an exception.


was (Author: tilman):
Can you build from source? If yes, open COSStream.java, and add
{code:java}IOUtils.closeQuietly(randomAccess);{code}
above 
{code:java}randomAccess = scratchFile.createBuffer();{code}
at two places.

> Memory leak due to soft reference caching
> -----------------------------------------
>
>                 Key: PDFBOX-4396
>                 URL: https://issues.apache.org/jira/browse/PDFBOX-4396
>             Project: PDFBox
>          Issue Type: Bug
>    Affects Versions: 2.0.12
>         Environment: JDK10; G1
>            Reporter: Ben Manes
>            Priority: Major
>         Attachments: #2 - memory leak 2.png, #2 - memory leak.png, memory leak 2.png, memory leak.png
>
>
> In a heap dump, it appears that DefaultResourceCache is retaining 5.3 GB of memory due to buffered images (via PDImageXObject). I suspect that G1 is not collecting soft references across all regions before it out-of-memory errors.
> In PDFBOX-4389, I discovered very slow PDDocument#load times due to a JDK10 I/O bug. Previously I was loading the document to render each page, but this took 1.5 minutes. To work around that bug I reused the document instance across pages. This seems to have fail because the pages were cached and not cleared by the GC.
> The DefaultResourceCache does not prune its cache entries when the soft references are collected. Like WeakHashMap, it should use a ReferenceQueue, poll it on every access, and prune accordingly.
> Thankfully PDDocument#setResourceCache exists. For now I am going to reset the cache to a new instance after a page has been rendered. The entries should no longer be reachable and be GC'd more aggressively. If that doesn't work, I'll either replace the cache (e.g. with Caffeine) or disable it by setting the instance to null.
> I think the desired fix is to prune the DefaultResourceCache and, ideally, reconsider usage of soft references (as they tend to be poor in practice). 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@pdfbox.apache.org
For additional commands, e-mail: dev-help@pdfbox.apache.org