When creating images using FopImageFactory, instances of images are stored in FopImageFactory.m_urlMap so that further request for the same image can be resolved without reloading and constructing the image. This is problematic for long-running FOP instances for two reasons: - If the image changes, the changes are never picked up. - Memory useage will only ever increase. A simple fix would be to use a java.util.WeakHashMap, but weak references don't work properly in 1.2 and 1.3 (apparently) and WeakHashMap isn't available in 1.1 or 1.0. I'll assign this to myself for now because the fix outlined above should be quite straight-forward, and I'll probably get around to fixing it in the course of my background-image work.
I ran into this as well; it was a killer for our app, which uses it as a snapshot/report facility for a map view via SVG and FO. Both memory usage and reuse of images which have changed on disk are a big problem. Currently I am disabling the cache altogether; even commented out the variable to be sure. Just using weak references would help with memory, but does not solve the stale image problem - for that you need a staleness check, probably in your *Reader implementations. You could go by date or something I suppose - there'd be problems occasionally but that would be better than nothing. Rather than check for newer modifiedDate I would just save the original modified date and check for if it changed at all-
You're right about the staleness check, but only if FOP is continually processing. As soon as it gets a breather and a thorough GC pass occurs, then the cached images should get reclaimed and reloaded. But yeah, using the image's last modification date (if present) would be the way to go. If no last modification date is given, I'd cache it for the duration of the current document only.
*** Bug 10941 has been marked as a duplicate of this bug. ***
This memory problem also has a file problem: we create a temporary directory that contains all necessary files for FOP transforming, incl. images. After FOP transforming, I can't delete this temporary directory because the (used) image files can't be deleted. Even though I call driver.reset() or release all XML/FOP objects. Only after i exit the application, i'm able to delete those files through Windows. Is there any chance to get a fix for this problem in the 0.20.x cycle or do we have to wait until the completely new fop is released (sometime in the future)?
The caching has been improved and streams are being closed - see the patch in bug #34308 . I'm leaving this bug open because image changes are not picked up yet.
Reset assignee so mails go to list.
no such class FopImageFactory
batch transition resolved+wontfix to closed+wontfix
batch transition resolved+wontfix to closed+wontfix; if you believe this remains a bug and can demonstrate it with appropriate input FO file and output PDF file (as applicable), then you may reopen