Bug 8003 - FopImageFactory never releases cached images
Summary: FopImageFactory never releases cached images
Status: CLOSED WONTFIX
Alias: None
Product: Fop - Now in Jira
Classification: Unclassified
Component: images (show other bugs)
Version: 0.20.5
Hardware: All All
: P3 major
Target Milestone: ---
Assignee: fop-dev
URL:
Keywords:
: 10941 (view as bug list)
Depends on:
Blocks:
 
Reported: 2002-04-12 07:56 UTC by Michael Gratton
Modified: 2012-04-30 00:17 UTC (History)
3 users (show)



Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Michael Gratton 2002-04-12 07:56:02 UTC
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.
Comment 1 preavis 2002-04-24 16:45:53 UTC
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-
Comment 2 Michael Gratton 2002-04-25 04:35:23 UTC
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.
Comment 3 Oleg Tkachenko 2002-11-19 17:03:35 UTC
*** Bug 10941 has been marked as a duplicate of this bug. ***
Comment 4 M.H. 2004-07-30 08:05:24 UTC
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)?
Comment 5 Tino Schwarze 2005-04-05 18:29:34 UTC
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.
Comment 6 Mark Thomas 2009-06-10 13:24:17 UTC
Reset assignee so mails go to list.
Comment 7 Glenn Adams 2012-04-05 05:32:15 UTC
no such class FopImageFactory
Comment 8 Glenn Adams 2012-04-30 00:14:45 UTC
batch transition resolved+wontfix to closed+wontfix
Comment 9 Glenn Adams 2012-04-30 00:17:14 UTC
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