java.lang.OutOfMemoryError: PermGen space error with Jetty
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
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.