java.lang.OutOfMemoryError: PermGen space error with Jetty

Question

I am currently getting an java.lang.OutOfMemoryError: PermGen space. I am using Jetty and Linux Ubuntu. I have tried reading and attempting the different solutions that were provided in previous similar questions but I am not having any success. One similar question was

Dealing with “java.lang.OutOfMemoryError: PermGen space” error

But these solutions seem to be using Tomcat instead of Jetty. I keep getting the out of memeory error if I redeploy my service a few times. For example to test this I am going to my webapps folder and running touch *.xml to update the time stamp then re-run jetty and I get the out of memory error. In my jetty folder (the one that includes bin, doc, etc, lib, logs, modules, start.jar) I am running

java -jar ../start.jar

But this gives me the error. I then tried what I read in the other examples such as:

java -jar ../start.jar JAVA_OPTS="-Xms256m -Xmx512m -XX:+CMSClassUnloadingEnabled -XX:+CMSPermGenSweepingEnabled"

or

-XX:+CMSClassUnloadingEnabled -XX:+CMSPermGenSweepingEnabled

or

-XX:MaxPermSize=128m

Then when I go to firefox and navigate to localhost:8080 and refresh, in the terminal I keep getting the error

java.lang.OutOfMemoryError: PermGen space

Answer 1

There is nothing you can do except raising your MaxPermSize to an higher value (eg. 1024m):

-XX:MaxPermSize=1024m

This is a common problem, and is also explained in Jetty Documentation - Prevent Memory Leaks section:

Permgen problems

The JSP engine in Jetty is Jasper. This was originally developed under the Apache Tomcat project, but over time has been forked by many different projects. All jetty versions up to 6 used Apache-based Jasper exclusively, with Jetty 6 using Apache Jasper only for JSP2.0. With the advent of JSP 2.1, Jetty 6 switched to using Jasper from Sun's Glassfish project, which is now the reference implementation.

All forks of Jasper suffer from a problem whereby the permgen space can be put under pressure by using jsp tag files. This is because of the classloading architecture of the jsp implementation. Each jsp file is effectively compiled and its class loaded in its own classloader so as to allow for hot replacement. Each jsp that contains references to a tag file will compile the tag if necessary and then load it using its own classloader. If you have many jsps that refer to the same tag file, then the tag's class will be loaded over and over again into permgen space, once for each jsp. The relevant Glassfish bug report is bug # 3963, and the equivalent Apache Tomcat bug report is bug # 43878. The Apache Tomcat project has already closed this bug report with status WON'T FIX, however the Glassfish folks still have the bug report open and have scheduled it to be fixed. When the fix becomes available, the Jetty project will pick it up and incorporate into our release program.

Answer 2

Hopefully you'll be able to get rid of these problems simply by using my ClassLoader Leak Prevention library. There are a lot of different mistakes that can cause these kinds of memory leaks, both in your own code and in third party libraries. More information about the problem, how to track it down and known offenders, can be found in this blog series of mine. Specifically note this bug in Jetty itself that may cause these kinds of leaks for some versions.