OutOfMemoryError: PermGen Space — Jasper Report with Spring running on Tomcat

Question

Our web application encounter a complicated situation

It is a Spring application developed by STS/Tomcat 7. After the application been integrated with <

Answer 1

The exception occurs when there are too many .class files in the permgen space in the JVM which cannot be garbage collected due to its references to an object outside the AppClassLoader. It generally points out to some memory leak your applciation.

This post has a lucid explanation of java.lang.OutOfMemoryError: PermGen space error and a following post has suggestions on how to fix it. A similiar (but not exactly the same) question was asked on SO, letting you know if you missed it. I hope it helps.

As jakub has mentioned setting -XX:+CMSClassUnloadingEnabled -XX:+CMSPermGenSweepingEnabled or setting a higher value for XX:MaxPermSize might work for you. But from what I have read, it isn't a permanent solution it seems. (I am not a master in this :)).

Answer 2

Try setting these parameters in your VM. These should enable GC cleaning your permGen.

-XX:+UseConcMarkSweepGC
-XX:+CMSPermGenSweepingEnabled
-XX:+CMSClassUnloadingEnabled

Answer 3

I have developed a web application which uses JasperReports 4.5.1

I use Tomcat 6.0.26 as a container. (Win7, JDK 1.6.0_25)

When shutdown the tomcat,it throw :

The web application created a ThreadLocal with key of type [net.sf.jasperreports.engine.util.JRFontUtil$1] (value [net.sf.jasperreports.engine.util.JRFontUtil$1@7892f1]) and a value of type [java.util.HashSet] (value [[]]) but failed to remove it when the web application was stopped. This is very likely to create a memory leak.

Please visit the website:

http://community.jaspersoft.com/questions/534340/memory-leak-jr-373

Answer 4

Since the PermGen mainly contains class metadata, and constant and interned Strings, you can search in two directions:

• check that the webapp does not contain (too many) useless jars, which might get loaded due to scanning

• see if you have lots of constant Strings (lots of large JSPs, for example) using a heap dump, or if your code uses String.intern()

---

Actually, you did not specify which version of Java you were using: with Java 7, the String might not be an issue.

What you could do is to observe the application with JVisualVM, using the VisualGC plugin, to see the state of the generations, the number of loaded classes and whether there's a surge in either at the time of the OOM, or if it's a slow build-up.

Answer 5

Thank you everyone for giving solution about this issue, I have identified the problem specifically to my situation and here is the solution:

Use .jasper instead of .jrxml as template !

As we know .jasper is a compiled template as well as .jrxml is ASCII source code for the template, so if we use raw source code file (jrxml) as template in current spring application then at least spring frame work has to compile the source code file. That's a question of efficiency left to Spring framework as it is the jasper bean to handle the compilation and it is not guaranteed the compilation executed only once and only happens when the application starting.

In short, after replace all templates with .jasper file, the log size has been significantly reduced and haven't seen the out of memory issue any more. I guess Spring container may be consume a lot of resource to compile jrxml to jasper at runtime. So it could be something should've improved by Jasper or Spring....