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.
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.
This issue happens with iterative deployment many times. I have faced this many times. Please refer the below JIRA link for glassfish bug:
http://java.net/jira/browse/GLASSFISH-587
If you are using Windows, try killing the glassfish process (java.exe *32) with Task Manager and then restarting the server.
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)