DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10941>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10941 Memory leaks when using dynamic images Summary: Memory leaks when using dynamic images Product: Fop Version: all Platform: PC OS/Version: Windows NT/2K Status: NEW Severity: Major Priority: Other Component: pdf renderer AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Hi, I have discovered some memory leaks when creating dynamic reports with dynamic (gif) image files. The problem is that image files seem to be cached and not released anymore, even when removing the fop driver object or calling the driver.reset() method. Since we are making dynamic reports and all charts in it are stored with unique filenames (to prevent concurrency problems between users), every created report keeps about 40 kb of memory in memory. After a few days, this results in tomcat to crash because the system gets out of memory (with heap size of 256 MB). When I always use the same GIF filenames and start a one user test repeatingly making reports for one user, one after the other, there is no memory leak. This means that the memory leak is caused by caching the image files and never releasing them. When the same filenames are reused over and over again, the cached image files are overwritten for every new report. After investigating the FOP source code (0.20.4) I discovered at least one problem in the FopImageFactory.java class: There is a private static Hashtable "m_urlMap" that caches all image URLs but never releases these URLs. Since it is a static map, the URLs are not even released after removing the fop objects from memory. When I solved this problem on my PC (by clearing the m_urlMap after calling the Driver.Reset method) there is still memory leak of about 30 kb left. Does anyone know about this problem and is there a possible work around (except from reusing the filenames)? Thanks, Dominique De Ridder --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]