PermGen space error - Glassfish Server

Question

I am running java web application using Hibernate and glassfish Server. I am getting

java.lang.OutOfMemoryError: PermGen space exception when after I deploying it several times.

I tried -XX:MaxPermSize=128M in my Environment variables, but it doesn't work.

Answer 1

To solve this problem ( in linux based os ) do following

1) increase memory (so that this problem don't come frequently ) by configuring "domain.xml" in

/glassfish/domain/domain1/config

search for

<jvm-options>-XX:MaxPermSize=

set it to higher value eg- 198m or 256m

2) kill the glassfish process to free the port on which it was running ( in my case it was 8686) open terminal (in linux based os) and type -

sudo netstat -npl | grep 8686

this will result in something like..

tcp6 0 0 :::8686 :::* LISTEN 3452/java

next use

kill -9 3452 to kill that process ( 3452 in this case )

Now try to start glassfish, it should start.

Answer 2

This is class loader memory leak. Each time you redeploy the application, a new classloader is created for it and all classes of your application are loaded again. This consumes memory in the perm gen space.

The old classloader and all its loaded classes have to be garbage collected, otherwise you will eventually run into a PermGen space OOME after deploying multiple times. This does not work if an object loaded by an outside classloader holds a reference to any object loaded by the old classloader. This article gives a good explanation of the problem.

Generally, classloader leaks are difficult to analyze and sometimes difficult to fix. To find out why the old classloaders are not garbage collected, you have to use a profiler. In JProfiler, use the heap walker, select the glassfish classloader objects and use the incoming references view to check for paths to garbage collector roots.

The class loader class is called org.apache.servlet.jasper.JasperLoader. Here's a screenshot of a regular situation, where the class loader is only held by live instances of loaded objects.

In your situation, you should see references from outside objects. Another common cause of a classloader leak in web containers is a background thread that is not stopped. Google Guice for example has such a bug in 3.0.

(Disclaimer: my company develops JProfiler)