permgen leak

#26758

I’m just starting to explore PD4ML. I’m using the following environment.

OS: Windows 7 Home Premium 64 bit
JDK / JRE: 1.7.0_05 64 bit
Server: Tomcat 6.0.35
IDE: NetBeans 7.1.2
Profiler: VisualVM 1.3.4
PD4ML: 3.8.0fx6

Simple JSP pages (all text) with or without styling seem to work fine. Performance is reasonable, and the output works as expected.

However, when I load images I run into problems. The images work correctly and appear correctly in the rendered PDF. However on unloading the application I get a memory leak warning from Tomcat’s manager (I have a Listener that starts the AWT event thread).

After doing a complete garbage collection and taking a heap dump, I do indeed see instances of org.zefer still in the heap. It appears that PD4ML has registered the images as icon types in java.awt.MediaTracker and not removed them after rendering.

Is there any way to force PD4ML to unregister the images from within JSP? I’ve tried setting the system property -Dpd4ml.cache.enable=false as part of JAVA_OPTS in setenv.sh when I start up Tomcat. This shows up properly in VisualVM, but has no effect on the permgen leak.

I’ve included the source as an attachment.

Thanks for any pointers.
/mde/

#29074

After a little more poking around with VisualVM, this seems to be the result of a java.security.ProtectionDomain instance hanging onto the web application. This gets loaded when rendering is triggered with an image.

Clearing caches with clearCache obviously won’t help. At this point, I’m not sure how to manage the issue.

Any thoughts would be greatly appreciated.

#29075

Hmm… In PD4ML sources there is no explicit references to java.awt.MediaTracker.

In PD4ML images are loaded from input stream to a byte array. After an image type analyze, in most of the cases it creates Image instance with

[language=java:tohf53k2]Image img = new ImageIcon(idata).getImage();[/language:tohf53k2]

As I see, the call implicitly involves the media tracker. However it is not obvious how to unregister the image out of there.

-Dpd4ml.cache.images.in.tmp.dir=true JVM flag (or an identical dynamic parameter, passed via API) forces PD4ML to immediately dump loaded image bytes to a TMP file and to set the above img = null. Now I am not sure if that is enough, bearing in mind the media tracker. Do you have an idea what needs to be done there?

#29076

@PD4ML wrote:

-Dpd4ml.cache.images.in.tmp.dir=true JVM flag (or an identical dynamic parameter, passed via API) forces PD4ML to immediately dump loaded image bytes to a TMP file and to set the above img = null. Now I am not sure if that is enough, bearing in mind the media tracker. Do you have an idea what needs to be done there?

I’m not sure what needs to be done. Setting that property at the JVM level does not seem to impact the permgen leak. Also, using the API directly and calling clearCache() does not seem to help.

An interesting observation on Glassfish is that the images (resources/icons, resources/dialogs) seem to be unpacked. Does the code traverse the classpath using ResourceAsStream and cache the PD4ML – supplied images before loading user – supplied images? I’ll take a look with VisualVM and see if these images are registered in MediaTracker.

Being a systems architect and not a full time Java developer, I hope I’m not wandering too far off in the weeds.

Thanks for the reply.
/mde/

[Author]

Posts