I don't know any easy answers to this sort of problem, but I can suggest several avenues of investigation.....
If you are running on solaris or linux then Sun has several tools available that you can use to diagnose what is using the Perm Gen memory. Have a look at http://java.sun.com/j2se/1.5/pdf/jdk50_ts_guide.pdf In particular http://java.sun.com/j2se/1.5.0/docs/tooldocs/share/jmap.html with the -permstat option might be able to tell you which classloader is the culprit. The perm gen space is also used when generating class files from JSPs. For servers with large numbers of JSP pages and/or frequent redeployments I've seen quite a large use of the perm gen space. It may also be worth increase the max space to see if that helps. Generally 128M is enough but I have seen a couple of situations where it needed to be larger. If you double the perm gen & hit out of memory at about half the frequency then you've got a leakage problem. Worth trying it just to confirm the problem. Another area to investigate is the use of ThreadLocal variables by your app or any libraries you use. Its very easy to setup up a circular reference to your (application) class loader when using ThreadLocals. Then when the app is redeployed the classloader & all its classes do not go away. If you find that the out of memory shows up more frequently when you redeploy apps more then this may be the cause. For some more detailed discussion/explanations of ThreadLocal & class loaders the following are worth a read (or just google ThreadLocal classloader). http://www.szegedi.org/articles/memleak.html http://opensource.atlassian.com/confluence/spring/pages/viewpage.action?page Id=2669 http://blog.arendsen.net/index.php/2005/02/22/threadlocals-and-memory-leaks- revisited/ Note: there are quite a few open source libraries that have had this problem at one time or another, so its worth investigating even if your code doesnt use ThreadLocals A final option may be to use a different JDK impl. E.g. I'm pretty sure that Jrockit (from bea) doesnt have a perm gen space & hence wont get the same problem (or at least might manifest it in a different way that is easier to diagnose). That's a pretty radical step tho, especially if your app is in production & has undergone a lot of testing in its current environment. Hope some of that helps. For what its worth, you have my sympathies. I've tried to find similar problems myself & its a long, hard road :( Regards, Ben Sommerville -----Original Message----- From: Henri Dupre [mailto:[EMAIL PROTECTED] Sent: Monday, 24 July 2006 2:12 PM To: Tapestry users Subject: Re: PermGen space - Caching is ON The tomcat folks state that there is no solution to this issue (in the tomcat FAQ)... I somehow hope that more recent versions of the JDK can solve this problem... I tried the new funky +CMS... java options but they don't seem to help the redeployment. Btw, I've seen this happening on JBoss too with a simple J2EE application. Henri. On 7/23/06, Jesse Kuhnert <[EMAIL PROTECTED]> wrote: > > No ideas at all, but if anyone thinks they get closer to finding > something let me know. I am definitely willing/able to work with > someone to solve problems like this, I just can't do it in the dark. > > On 7/23/06, Harvey, David <[EMAIL PROTECTED]> wrote: > > > > Thanks for your comments, discussion. However, this occurs when > > caching is turned on, i.e. > > -Dorg.apache.tapestry.disable-caching=false. > > > > I sure hope there's a fix, I don't know if MaxPermSize can be made > > any larger in production and it sounds from your discussion that > > making it larger will just delay the OOM condition anyway. > > > > Anybody else have any ideas? > > > > -----Original Message----- > > From: James Carman [mailto:[EMAIL PROTECTED] > > Sent: Sunday, July 23, 2006 6:03 AM > > To: Tapestry users > > Subject: Re: PermGen space > > > > Actually, Tapestry (and HiveMind as well) uses Javassist to generate > > classes at runtime, but all the rest is still true with Javassist as > > it > is > > with CGLIB (hibernate uses CGLIB). As Martin said, enabling caching > should > > fix the problem. Tapestry will only generate (and cache) the > > classes > for > > each page/component one time with caching enabled. In a production > > environment, you really shouldn't run into this, since you would > > have caching enabled and you wouldn't be hot redeploying your application. > > > > James > > > > > Hi all, > > > This problem is very common with Tapestry applications. This is > > > due to the fact that Tapestry uses cglib to generate classes at runtime. > > > Java uses a separate Heap space called "PermGenSpace" to put > > > meta-data about classes, which is never garbage collected (this is "normal" > > > since normally, classes never change...) but with cglib, classes > > > are generated, which add to the PermGenSpace. And the next time > > > your application is deployed, new classes are generated which add > > > to the PermGenSpace, etc... So it fills and become full. > > > So this problem is common to Java+Tapestry/cglib+deployed webapps. > > > I hope this explaination is clear. Else ask questions. > > > -jec > > > > > > Harvey, David a écrit : > > >> Hello all, > > >> > > >> We've been having occasional problems with PermGen out of space > > >> errors thrown during the execution of our Tapestry application. > > >> We usually get a stack trace with something about hivemind at the > > >> top > (see > > below). > > >> Then, of course, we have to restart our app server. Our > > >> environment is > > >> > > >> Tapestry 4.0.1 and Tacos4-Beta3 > > >> Jboss 4.0.3 sp1 (Tomcat 5.5 embedded) JRE 1.5.0_03 > > >> > > >> The java runtime is initialized with -XX:PermSize=96M > > >> -XX:MaxPermSize=128M > > >> > > >> The stack trace we get at various times is: > > >> > > >> 2006-07-20 17:25:11,415 ERROR > > >> [net.sf.tacos.ajax.impl.AjaxDirectServiceImpl] Error invoking > > >> listener on component $AjaxForm_40 > > >> org.apache.hivemind.ApplicationRuntimeException: PermGen space > > >> [context:/WEB-INF/pages/claims/addEdit.page, line 6, column 93] > > >> at > > >> org.apache.tapestry.engine.RequestCycle.rewindForm(RequestCycle.java: > > >> 461 > > >> ) > > >> at > > >> net.sf.tacos.ajax.components.AjaxForm.trigger(AjaxForm.java:418) > > >> at > > >> net.sf.tacos.ajax.impl.AjaxDirectServiceImpl.triggerComponent(Aja > > >> xDir > > >> ect > > >> ServiceImpl.java:348) > > >> . > > >> . > > >> . > > >> > > >> Caused by: java.lang.OutOfMemoryError: PermGen space > > >> > > >> > > >> Anybody have any clues as to what we can do about this? > > >> > > >> Regards, > > >> David Harvey > > >> Ingenix, Inc. > > >> > > >> "Secure Server BSK" made the following annotations on 07/21/2006 > > >> 03:28:13 PM ------------------------------"This e-mail, including > > >> attachments, may include confidential and/or proprietary > > >> information, and may be used only by the person or entity to > > >> which it is addressed. If the reader of this e-mail is not the > > >> intended recipient or his or her authorized agent, the reader is > > >> hereby notified that any dissemination, distribution or copying > > >> of this e-mail is prohibited. If you have received this e-mail in > > >> error, please notify the sender by replying to this message and > > >> delete this e-mail immediately." > > >> ============================== > > >> > > >> ----------------------------------------------------------------- > > >> ---- To unsubscribe, e-mail: > > >> [EMAIL PROTECTED] > > >> For additional commands, e-mail: [EMAIL PROTECTED] > > >> > > > > > > ------------------------------------------------------------------ > > > --- To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > James Carman, President > > Carman Consulting, Inc. > > > > > > -------------------------------------------------------------------- > > - To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > "Secure Server BSK" made the following annotations on 07/23/2006 > > 09:50:20 PM ------------------------------"This e-mail, including > > attachments, may include confidential and/or proprietary > > information, and may be used > only by > > the person or entity to which it is addressed. If the reader of this > e-mail > > is not the intended recipient or his or her authorized agent, the > > reader > is > > hereby notified that any dissemination, distribution or copying of > > this e-mail is prohibited. If you have received this e-mail in > > error, please notify the sender by replying to this message and > > delete this e-mail immediately." > > ============================== > > > > -------------------------------------------------------------------- > > - To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > -- > Jesse Kuhnert > Tacos/Tapestry, team member/developer > > Open source based consulting work centered around > dojo/tapestry/tacos/hivemind. > > -- Thanks, Henri. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
