fop-pdf-images and caching

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

fop-pdf-images and caching

Matt Kynaston
I'm using fop-pdf-images to load an external PDF to use as a background on all pages. Works great most of the time :)

However I've noticed a couple of things around caching. It might be my setup, but maybe someone can point me in the right direction before I start stepping through it.

First, I get a hit on the external PDF for each and every page. I've had a look at the PreloadPDF and it looks like it's meant to be caching, but apparently not. Is there some configuration I'm missing for this?

Second, if I rename the external PDF I get an error as expected. However renaming it back doesn't seem to be picked up immediately: it takes one or more runs before it's found again. 

Note that I've got an EventListener hooked up to throw an exception on (most) resource error events. Could that be short-circuiting things?

Thanks for any help

--
Matt Kynaston
Reply | Threaded
Open this post in threaded view
|

Re: fop-pdf-images and caching

Matt Kynaston

First, I get a hit on the external PDF for each and every page. I've had a look at the PreloadPDF and it looks like it's meant to be caching, but apparently not. Is there some configuration I'm missing for this?

Ah hah. Turns out I was looking at the trunk version of fop-pdf-images when I saw the caching stuff. That was removed before version 2.2 was tagged.

Going back to ticket FOP-2135 it looks like this "document level" cache was added to reduce the document size, not avoid repeated hits on remote resources. Caching the remote resource is handled by org.apache.xmlgraphics.image.loader.cache.ImageCache, which in turn checks isCachable() on the image. ImagePDF returns false for that :(

Does anyone have any insights into this? Is there any way to make a PDF image cacheable?

Second, if I rename the external PDF I get an error as expected. However renaming it back doesn't seem to be picked up immediately: it takes one or more runs before it's found again. 

Again, this is down to ImageCache, which is keeping track of invalid URLs for 60s.

Matt
Reply | Threaded
Open this post in threaded view
|

RE: fop-pdf-images and caching

Simon Steiner

Hi,

 

For the change see https://issues.apache.org/jira/browse/FOP-2693

If you cache PDDocument then close is never called on them and you get OOM eventually.

There was a finalize that called close but that wasn’t working on IBM JDK.

I think there were other issues.

 

Thanks

 

From: Matt Kynaston [mailto:[hidden email]]
Sent: 16 November 2017 13:32
To: [hidden email]
Subject: Re: fop-pdf-images and caching

 

 

First, I get a hit on the external PDF for each and every page. I've had a look at the PreloadPDF and it looks like it's meant to be caching, but apparently not. Is there some configuration I'm missing for this?

 

Ah hah. Turns out I was looking at the trunk version of fop-pdf-images when I saw the caching stuff. That was removed before version 2.2 was tagged.

 

Going back to ticket FOP-2135 it looks like this "document level" cache was added to reduce the document size, not avoid repeated hits on remote resources. Caching the remote resource is handled by org.apache.xmlgraphics.image.loader.cache.ImageCache, which in turn checks isCachable() on the image. ImagePDF returns false for that :(

 

Does anyone have any insights into this? Is there any way to make a PDF image cacheable?

 

Second, if I rename the external PDF I get an error as expected. However renaming it back doesn't seem to be picked up immediately: it takes one or more runs before it's found again. 

 

Again, this is down to ImageCache, which is keeping track of invalid URLs for 60s.

 

Matt

Reply | Threaded
Open this post in threaded view
|

Re: fop-pdf-images and caching

Matt Kynaston
Ouch! Looks like it's going to be easiest for me to convert the backgrounds to PNG then. 

But thanks for the info Simon.

Matt