For the last one week I have been trying in vain to resolve the OutOfMemory PermGen issue that I have run into. I guess its time I sought some expert advice.

I have been reading posts on what this error means and the potential offenders which cause this error. Primary amongst them being Tomcat (multiple context reloads), CGLIB, Hibernate and the byte code optimization that Hibernate uses.

My application has been built on JDK1.5 (1.5.0_05-b05), JBoss 4.0.5, Hibernate 3.3, JavaAssist 3.4, (the byte code optimizer used by Hibernate is JA3.4 not CGLIB), Spring 2.1 with a MySQL 5.0 backend.

The problem I face is that my application runs out of the PermGen almost every two days. Note that this happens without any context reload. Completely stumped as to why this is happening and how it could be resolved.

The application relies on Spring heavily both on the web tier and at the data access layer. Am using the Spring ORM Apis to talk to hibernate. The app also uses stateless EJBS primarily for transaction mgmt and to also make my business layer distributable in case I want to setup an EJB cluster later.

I have tried a few suggestions that I found on various forums -

the JVM options I am using are
------------------------------------------------------
-Xms1536m -Xmx1536m -XX:NewSize=768m -XX:MaxNewSize=768m -XX:SurvivorRatio=4 -XX:TargetSurvivorRatio=90 -XX:MaxTenuringThreshold=12
-XX:+UseConcMarkSweepGC -XX:+CMSIncrementalMode -XX:+CMSIncrementalPacing -XX:+CMSParallelRemarkEnabled -XX:+UseParNewGC -XX:PermSize=128m
-XX:MaxPermSize=128m -XX:+UseTLAB -XX:+CMSClassUnloadingEnabled -XX:+CMSPermGenSweepingEnabled
--------------------------------------------------------

The latest changes that I have made is -
increased the PermSize to 256m
disabled the bytecode optimization (-Dhibernate.bytecode.use_reflection_optimizer=false)

However, I am not sure if this will help am yet to find out.

While I wait to see how this goes, I wanted to know if there is anything else that I could do? I have also enabled a gc log (i see a lot of concurrent mode failure errors logged during Full GC, cant explain that), I have been observing the jmap histogram, do not find anything out of place there, have now started monitoring the heap utilization.

Let me also mention that I performed a load test using JMeter, 20 threads, 50 iterations, about 38 different pages of the site. The test concluded fine and the jvm memory utilization seemed normal (i did not monitor the perm gen though).

The app just runs out of permgen over a period of time.

Appreciate any help that I can get on this issue. Please do let me know if you need any more information from my end..

thanks in advance.

We are using Hibernate 3.3 with Spring 2.5. We are also experiencing a similar problem, but at deployment or restart. I can tell you that setting the hibernate.cglib.use_reflection_optimizer parameter to false is definitely not a solution, and has some rather nasty consequences. Not sure if it is limited to Oracle databases or not, but we found that outside of our individual sandboxes, the database connection was timing out. As soon as I reset the parameter back to true, the problem disappeared. We still have the Permgen problem, but we are moving to tomcat 6, and I believe that this problem is solved under tomcat 6.

Connie Irwin
MIT Lincoln Laboratory

There was a PermGen bug fixed in 1.5.0_07. (http://bugs.sun.com/bugdatabase/view_bu ... id=6319688)
Have you tried running your application in a newer 1.5 JVM?

We will also be upgrading to java 6, which will make the issue moot. However, how long ago did you upgrade, and where were you able to locate the jdk? I searched Sun's java site and was unable to locate any jdk but 6.

If we were to do an upgrade our sandboxes to jdk 1.5.0_07, we would have to upgrade all of our environments, dev, qa and prod as well. In addition to upgrading to tomcat 6, we made a strategic decision to go with jdk 6; it's been out for 2 yrs, and we run the risk of falling behind on the upgrade path. Unit and volume testing will certainly be interesting. We are also upgrading our servers to solaris 10 in order to support virtualization.
I'll keep you posted on any issues that come up.

Thanks again,

Connie Irwin

hey..

I switched to a newer version of JBoss (4.2.3) which has Tomcat 6 engine and I also upgraded to JDK 1.6.

Apart from these upgrades I made a few changes to my deployment structure - I had a few libraries (including commons_logging) as part of my war libraries - I have moved these out ever since. I suspect that commons_logging in the WEB-INF lib is what caused a leak in my case.

After moving to JBoss 4.2.3 and JDK 1.6 (one of its profiling tool Jmap helped me monitor the perm gen closely and be assured that the problem was solved) I have not run into any problems since.

Thanks
Naushad.

Does JBoss 4.2.3 support Java6? We use JBoss 4.2.1 and it explicitly states that Java6 is not supported.

Hi,

Never had any trouble coz of JBoss 4.2.3 and Jdk 1.6.

Before deciding to use 4.2.3 I went through its release notes and it does mention that it can run under Java 6.

-- quote --

A secondary target for this release was to improve support for Java 6. JBossAS 4.2.3.GA can be build with both JDK5
and JDK6. The JDK5 compiled binaries have undergone more rigorous testing, they constitute our certified version and
can run under both Java 5 & 6 VMs (with a few configuration changes for JDK6, see the configuration section below). The
JDK6 compiled binaries include support for the JDBC 4 APIs, but this should be considered experimental

-- unquote --

this is the link for more details.
http://sourceforge.net/project/shownote ... p_id=22866

I located an entire page on memory leaks associated with classloaders. Check out

http://opensource.atlassian.com/conflue ... ageId=2669

It has some interesting suggestions for profiling your container, and a very good write up on how classloaders work.

Thanks,

Connie