jBoss 4.0.2 deploying same WAR multiple times causes jBoss to crash because of PermGem/Out-of-Memory Errors

Question

I develop web applications and I use jBoss 4.0.2 and when I have redeployed my WAR several times with eclipse, jBoss will crash because it runs out of memory. And when I have to install new version to production enviroment, it will consume production servers memory, so that means I have to stop jBoss to prevent redeploying eat memory from customers server. Is there any work around for this problem?

Answer 1

Basically, no. Because of the way the JBoss classloaders work, each deployment will use up a chunk of PermGen that will not be released even if the application is undeployed.

You can mitigate the symptoms by ramping up the PermGen memory pool size to several hundred megs (or even gigs), which makes the problem easier to live with. I've also found that reducing the usage of static fields in your code (especially static fields that refer to large objects) reduces the impact on PermGen.

Ideally, I would not use hot deployment in production, but rather shut the server down, replace the WAR/EAR, then restart it.

Answer 2

I'm not sure it's linked, but I suspect it is - JBoss is not J2EE compliant as far as implementing application separation as it comes out of the box.

As it comes, there is one classloader into which all classes are put and thus it is not possible to unload classes and therefore you are going to have this problem. You can configure jboss to be more J2EE compliant in this respect.

Are you getting the "out of memory Permgen" or are you getting regular out of memory?

I also made progress by connecting JProfiler up to it and checking memory usage with this.

I ended up simply restarting Jboss all the time - didn't take up too much time.

Answer 3

Try this (which applies to Sun's Java):

-XX:+UseConcMarkSweepGC -XX:+CMSPermGenSweepingEnabled -XX:+CMSClassUnloadingEnabled -XX:MaxPermSize=128m

CMS can actually GC the permanent generation heap (the heap where your classes are). Setting MaxPermSize is unnecessary, but the default is low for an application server.