Re: PermGen space - Caching is ON
Hello, I just ran into a problem related to this thread. I have a class with 30 unit tests which tests a HiveMind service used by my Tapestry pages. About midway through execution I get a : java.lang.OutOfMemoryError: Java heap space. I guess I am doing something wrong. I know just enough about HiveMind to be dangerous. Regards, -Ryan On Monday, July 24, 2006, at 11:01AM, Martin Strand <[EMAIL PROTECTED]> wrote: >What I meant is that the redeploy ant task you mentioned likely causes the >same error as Eclipse's hot redeploy - old unused classes are still left >in permgen space. Restarting tomcat rather than redeploying would probably >cure the problem. > >Also, if you check google: >http://www.google.com/search?num=25&hl=en&lr=&client=opera&rls=en&q=redeploy+OutOfMemoryError+PermGen&btnG=Search > >you end up with a recent article on the subject: >http://www.jroller.com/page/agileanswers?entry=preventing_java_s_java_lang > >where the guy suggests jrockit instead, but you said you already tried >that... :\ >But someone else there says "After upgrading to jdk1.5.0_07 my Perm Gen >Space gets gc'ed like it should be - no increase of Perm Gen Space, no >code changes." so perhaps you could give update 7 a try. > >Martin > >On Mon, 24 Jul 2006 18:56:48 +0200, <[EMAIL PROTECTED]> wrote: > >> This is in a production environment. There isn't any hot deploying >> happening. We just let the application run. >> >> Our production environment virtual machine args: >> -Xms128m -Xmx1024m -Dorg.apache.tapestry.disable-caching=false >> -XX:MaxPermSize=128m >> >> I don't know how much larger the PermSize can be. >> >> Thanks for your help. >> >> >> -Original Message- >> From: Martin Strand [mailto:[EMAIL PROTECTED] >> Sent: Monday, July 24, 2006 10:31 AM >> To: Tapestry users >> Subject: Re: PermGen space - Caching is ON >> >> Hot redeploy is when you edit your code in Eclipse and Eclipse >> automatically adds the new classes to the running JVM and reloads the >> context. That would leave the old classes in the classloader, eventually >> leading to the OOM error you're seeing. >> >> I'm far from an expert on the subject, but redeploying probably doesn't >> unload any classes so every redeploy would be the same as uncaching all >> Tapestry pages/components. You're sort of running Tapestry with >> "org.apache.tapestry.disable-caching" set to somewhere between true and >> false. ;) If you don't ever redeploy your app, just deploy it once and >> then let it run, do you still get that error? >> >> Martin >> >> On Mon, 24 Jul 2006 17:42:54 +0200, Henri Dupre <[EMAIL PROTECTED]> >> wrote: >> >>> Yes I've seen the same issue on linux and windows with all JDKs using >>> Tomcat or JBoss. >>> I'd be curious to know if other containers such as Jetty, Weblogic or >>> Websphere have better solutions... >>> I'm not sure what do you refer as "hot redeploy"... We are using the >>> tomcat ant tasks to redeploy into tomcat. >>> >>> Henri. >>> >>> >>> On 7/24/06, Martin Strand <[EMAIL PROTECTED]> wrote: >>>> >>>> So you're seeing this in your production environment, not only when >>>> you hot redeploy from Eclipse? >>>> >>>> Martin >>>> >>>> On Mon, 24 Jul 2006 03:50:17 +0200, 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 >&g
Re: PermGen space - Caching is ON
What I meant is that the redeploy ant task you mentioned likely causes the same error as Eclipse's hot redeploy - old unused classes are still left in permgen space. Restarting tomcat rather than redeploying would probably cure the problem. Also, if you check google: http://www.google.com/search?num=25&hl=en&lr=&client=opera&rls=en&q=redeploy+OutOfMemoryError+PermGen&btnG=Search you end up with a recent article on the subject: http://www.jroller.com/page/agileanswers?entry=preventing_java_s_java_lang where the guy suggests jrockit instead, but you said you already tried that... :\ But someone else there says "After upgrading to jdk1.5.0_07 my Perm Gen Space gets gc'ed like it should be - no increase of Perm Gen Space, no code changes." so perhaps you could give update 7 a try. Martin On Mon, 24 Jul 2006 18:56:48 +0200, <[EMAIL PROTECTED]> wrote: This is in a production environment. There isn't any hot deploying happening. We just let the application run. Our production environment virtual machine args: -Xms128m -Xmx1024m -Dorg.apache.tapestry.disable-caching=false -XX:MaxPermSize=128m I don't know how much larger the PermSize can be. Thanks for your help. -Original Message- From: Martin Strand [mailto:[EMAIL PROTECTED] Sent: Monday, July 24, 2006 10:31 AM To: Tapestry users Subject: Re: PermGen space - Caching is ON Hot redeploy is when you edit your code in Eclipse and Eclipse automatically adds the new classes to the running JVM and reloads the context. That would leave the old classes in the classloader, eventually leading to the OOM error you're seeing. I'm far from an expert on the subject, but redeploying probably doesn't unload any classes so every redeploy would be the same as uncaching all Tapestry pages/components. You're sort of running Tapestry with "org.apache.tapestry.disable-caching" set to somewhere between true and false. ;) If you don't ever redeploy your app, just deploy it once and then let it run, do you still get that error? Martin On Mon, 24 Jul 2006 17:42:54 +0200, Henri Dupre <[EMAIL PROTECTED]> wrote: Yes I've seen the same issue on linux and windows with all JDKs using Tomcat or JBoss. I'd be curious to know if other containers such as Jetty, Weblogic or Websphere have better solutions... I'm not sure what do you refer as "hot redeploy"... We are using the tomcat ant tasks to redeploy into tomcat. Henri. On 7/24/06, Martin Strand <[EMAIL PROTECTED]> wrote: So you're seeing this in your production environment, not only when you hot redeploy from Eclipse? Martin On Mon, 24 Jul 2006 03:50:17 +0200, 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 duri
RE: PermGen space - Caching is ON
This is in a production environment. There isn't any hot deploying happening. We just let the application run. Our production environment virtual machine args: -Xms128m -Xmx1024m -Dorg.apache.tapestry.disable-caching=false -XX:MaxPermSize=128m I don't know how much larger the PermSize can be. Thanks for your help. -Original Message- From: Martin Strand [mailto:[EMAIL PROTECTED] Sent: Monday, July 24, 2006 10:31 AM To: Tapestry users Subject: Re: PermGen space - Caching is ON Hot redeploy is when you edit your code in Eclipse and Eclipse automatically adds the new classes to the running JVM and reloads the context. That would leave the old classes in the classloader, eventually leading to the OOM error you're seeing. I'm far from an expert on the subject, but redeploying probably doesn't unload any classes so every redeploy would be the same as uncaching all Tapestry pages/components. You're sort of running Tapestry with "org.apache.tapestry.disable-caching" set to somewhere between true and false. ;) If you don't ever redeploy your app, just deploy it once and then let it run, do you still get that error? Martin On Mon, 24 Jul 2006 17:42:54 +0200, Henri Dupre <[EMAIL PROTECTED]> wrote: > Yes I've seen the same issue on linux and windows with all JDKs using > Tomcat or JBoss. > I'd be curious to know if other containers such as Jetty, Weblogic or > Websphere have better solutions... > I'm not sure what do you refer as "hot redeploy"... We are using the > tomcat ant tasks to redeploy into tomcat. > > Henri. > > > On 7/24/06, Martin Strand <[EMAIL PROTECTED]> wrote: >> >> So you're seeing this in your production environment, not only when >> you hot redeploy from Eclipse? >> >> Martin >> >> On Mon, 24 Jul 2006 03:50:17 +0200, 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 &g
RE: PermGen space - Caching is ON
To answer Martin's question: This is in a production environment. There isn't any hot deploying happening. Our production environment virtual machine args: -Xms128m -Xmx1024m -Dorg.apache.tapestry.disable-caching=false -XX:MaxPermSize=128m I don't know how much larger the PermSize can be. Thanks for your help. -Original Message- From: Konstantin Ignatyev [mailto:[EMAIL PROTECTED] Sent: Monday, July 24, 2006 9:52 AM To: Tapestry users Subject: Re: PermGen space - Caching is ON Just an idea: could it be that some aspectizing container (Spring or HiveMind)has a not quite correctly written service that is not a singleton, but a (bad) factory. That factory might create new aspectized class every time and then instantiate object instead of creating a weaved class once and then creating objects from it. That would clog PermGen space. Do you run anything non-standard or suspicious? --- Henri Dupre <[EMAIL PROTECTED]> wrote: > Yes I've seen the same issue on linux and windows with all JDKs using > Tomcat or JBoss. > I'd be curious to know if other containers such as Jetty, Weblogic or > Websphere have better solutions... > I'm not sure what do you refer as "hot redeploy"... > We are using the tomcat > ant tasks to redeploy into tomcat. > > Henri. > > Konstantin Ignatyev PS: If this is a typical day on planet earth, humans will add fifteen million tons of carbon to the atmosphere, destroy 115 square miles of tropical rainforest, create seventy-two miles of desert, eliminate between forty to one hundred species, erode seventy-one million tons of topsoil, add 2,700 tons of CFCs to the stratosphere, and increase their population by 263,000 Bowers, C.A. The Culture of Denial: Why the Environmental Movement Needs a Strategy for Reforming Universities and Public Schools. New York: State University of New York Press, 1997: (4) (5) (p.206) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] "Secure Server GDV" made the following annotations on 07/24/2006 12:13:46 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]
Re: PermGen space - Caching is ON
Hot redeploy is when you edit your code in Eclipse and Eclipse automatically adds the new classes to the running JVM and reloads the context. That would leave the old classes in the classloader, eventually leading to the OOM error you're seeing. I'm far from an expert on the subject, but redeploying probably doesn't unload any classes so every redeploy would be the same as uncaching all Tapestry pages/components. You're sort of running Tapestry with "org.apache.tapestry.disable-caching" set to somewhere between true and false. ;) If you don't ever redeploy your app, just deploy it once and then let it run, do you still get that error? Martin On Mon, 24 Jul 2006 17:42:54 +0200, Henri Dupre <[EMAIL PROTECTED]> wrote: Yes I've seen the same issue on linux and windows with all JDKs using Tomcat or JBoss. I'd be curious to know if other containers such as Jetty, Weblogic or Websphere have better solutions... I'm not sure what do you refer as "hot redeploy"... We are using the tomcat ant tasks to redeploy into tomcat. Henri. On 7/24/06, Martin Strand <[EMAIL PROTECTED]> wrote: So you're seeing this in your production environment, not only when you hot redeploy from Eclipse? Martin On Mon, 24 Jul 2006 03:50:17 +0200, 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(AjaxDir >>> 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 receive
Re: PermGen space - Caching is ON
Just an idea: could it be that some aspectizing container (Spring or HiveMind)has a not quite correctly written service that is not a singleton, but a (bad) factory. That factory might create new aspectized class every time and then instantiate object instead of creating a weaved class once and then creating objects from it. That would clog PermGen space. Do you run anything non-standard or suspicious? --- Henri Dupre <[EMAIL PROTECTED]> wrote: > Yes I've seen the same issue on linux and windows > with all JDKs using Tomcat > or JBoss. > I'd be curious to know if other containers such as > Jetty, Weblogic or > Websphere have better solutions... > I'm not sure what do you refer as "hot redeploy"... > We are using the tomcat > ant tasks to redeploy into tomcat. > > Henri. > > Konstantin Ignatyev PS: If this is a typical day on planet earth, humans will add fifteen million tons of carbon to the atmosphere, destroy 115 square miles of tropical rainforest, create seventy-two miles of desert, eliminate between forty to one hundred species, erode seventy-one million tons of topsoil, add 2,700 tons of CFCs to the stratosphere, and increase their population by 263,000 Bowers, C.A. The Culture of Denial: Why the Environmental Movement Needs a Strategy for Reforming Universities and Public Schools. New York: State University of New York Press, 1997: (4) (5) (p.206) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: PermGen space - Caching is ON
Yes I've seen the same issue on linux and windows with all JDKs using Tomcat or JBoss. I'd be curious to know if other containers such as Jetty, Weblogic or Websphere have better solutions... I'm not sure what do you refer as "hot redeploy"... We are using the tomcat ant tasks to redeploy into tomcat. Henri. On 7/24/06, Martin Strand <[EMAIL PROTECTED]> wrote: So you're seeing this in your production environment, not only when you hot redeploy from Eclipse? Martin On Mon, 24 Jul 2006 03:50:17 +0200, 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(AjaxDir >>> 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
Re: PermGen space - Caching is ON
So you're seeing this in your production environment, not only when you hot redeploy from Eclipse? Martin On Mon, 24 Jul 2006 03:50:17 +0200, 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(AjaxDir 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." == --
Re: PermGen space - Caching is ON
On 7/24/06, Ben Sommerville <[EMAIL PROTECTED]> wrote: A final option may be to use a different JDK impl. E.g. I'm pretty sure that Jrockit (from bea) doesn't 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. I've seen exactly the same issue with JRockit and unfortunately, nothing more detailed to help diagnosing the problem. In addition, in the latests versions of JRockit, they made their memory leak tool only available to JRockit licensed customers... And that far I've found sun's Jmap and Jhat much more powerful. Something in the redeployment is defenitly different with the JDK 1.6though. On windows, a redeployment is way faster than with previous versions. Thanks, Henri.
RE: PermGen space - Caching is ON
Roughly 100 unique pages. Several pages have multiple Ajax round trips for autocomplete using the Tacos toolkit. -Original Message- From: James Carman [mailto:[EMAIL PROTECTED] Sent: Monday, July 24, 2006 5:03 AM To: Tapestry users Subject: RE: PermGen space - Caching is ON How many pages does your application have roughly? > 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(AjaxDi >>> r >>> 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." >>> == >>> >>> --
RE: PermGen space - Caching is ON
How many pages does your application have roughly? > 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(AjaxDir >>> 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
RE: PermGen space - Caching is ON
"Harvey, David " <[EMAIL PROTECTED]> wrote on 24/07/2006 02:50:17: > 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. The default max perm size is *small* any application which loads a lot of classes has a chance of running into this. You're right about it only delaying the problem, but it could be delayed indefinitely. d. *** The information in this e-mail is confidential and for use by the addressee(s) only. If you are not the intended recipient please delete the message from your computer. You may not copy or forward it or use or disclose its contents to any other person. As Internet communications are capable of data corruption Student Loans Company Limited does not accept any responsibility for changes made to this message after it was sent. For this reason it may be inappropriate to rely on advice or opinions contained in an e-mail without obtaining written confirmation of it. Neither Student Loans Company Limited or the sender accepts any liability or responsibility for viruses as it is your responsibility to scan attachments (if any). Opinions and views expressed in this e-mail are those of the sender and may not reflect the opinions and views of The Student Loans Company Limited. This footnote also confirms that this email message has been swept for the presence of computer viruses. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: PermGen space - Caching is ON
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
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(AjaxDir > >> 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. > > >
Re: PermGen space - Caching is ON
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(AjaxDir >> 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.
RE: PermGen space - Caching is ON
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(AjaxDir >> 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." == -
