I solved this issue for me by using a different Java implementation. Instead of using Sun's JVM, we run the JBoss AS on Bea JRockit. Maybe this is an option for you too.
Thanks for your reply,
but JRockit is not an option, as JRockit will load the classes in the heap memory. But the classes won't be unloaded too. The heap space grows dynamicly. But the perm Gen from the JDK doesn't grow.
We updated our JDK to 1.6.0_12 but we still get these errors. Is this a known error in Portal or Jboss itself?
Thanks in advance.
if your problem is still there:
JAVA_OPTS="$JAVA_OPTS -Xmx256m -Xms256m -XX:PermSize=256m -XX:MaxPermSize=256m"
Please tune them for your environment :)
Thanks for your reply. But the problem isn't the size of the perm gen. The problem is, that the classes within the permGen won't release after they are no longer needed. So the PermGen will grow, grow and grow till you get a permGen Exception. Right now we handle the issue by doing a jojo of the jboss every night...
What do you mean by "wont be released when they are not needed".? Permgen space is used for loading class definition which is needed throughout the lifetime of serve. Unless a class is being loaded multiple times and there is a leak in class loader, you should not see permgen space grow after certain time.
We have not seen any random behavior with permgen space during load testing of JBoss Enterprise Portal Platform (EPP).
Sorry for my short uncleared explanation. When we do a hot undeploy of an portlet (In case of updating it) and deploy the newer version the classes of the old version wonâ€™t release from the perm Gen.
Which is why hot redeploy is not recommended for production, only for development, I can't find it at the moment but there are plenty of explanations about it and relate to some Sun JDK bug that has neven been fixed. Other JVM handles permgen space differently.
Unless you redeploy a new version every day you shouldn't have to restart every night. Also on a cluster there are better approach to keep having your portal running without any downtime.
Hi, what we researched was a blog entry from Frank Kiviet (http://blogs.sun.com/fkieviet/entry/how_to_fix_the_dreaded). The examples he used could we completly reproduce. But the result isn't a bug in JDK...