That is not the case! the jvm uses the PermGenSpace to store the classes meta-information (eg. needed for reflection). everytime Tapestry reloads and enhances a page a new class is generated and its meta-information gets stored in the PermGenSpace. Even if the same page class has been enhanced before because now its another class. Because the PermGenSpace does not get gc it will eventually, after many reloads, get a OutOfMemoryError.
This is a problem that occured to me often when developing T4 applications with the tapestry.cache parameter set to false because then the page classes would get enhanced (and written to the PermGenSpace) on every request. I never experienced such a exception with T5 because it uses an own classloader that is discarded (and the associated data from the PermGenSpace) before the pages are reloaded and enhanced. Also it is not a problem exclusive to Tapestry. If you use Hibernate, Spring, AOP and other frameworks that make heavy use of runtime class manipulation... can produce such exceptions. (just google it) the first thing you can do is to increase the permGenSpace of your jvm: eg.: --XX:MaxPermSize=256m btw. even i you used persist annotations extensively Tapestry would have a relativley small memory session footprint compared to other Web frameworks as Tapestry itself does not need the session - at least keeps the usage to a bare minimum. this is a consequence of the "static page/component tree dynamic behaviour" concept of Tapestry. other Web frameworks need the session to persist the component tree between requests because they can be changed dynamically and need to be restored on the next request. g, kris "Marcelo Lotif" <[EMAIL PROTECTED]> 13.06.2008 14:03 Bitte antworten an "Tapestry users" <users@tapestry.apache.org> An "Tapestry users" <users@tapestry.apache.org> Kopie Thema Re: Tomcat 5.5.26 + JDK 6_05 - java.lang.OutOfMemoryError: PermGen Space Hi guys, I had some problems like this too, and i want to know from you, tapestry experts: Do you think that the wrong usage of @Persist annotation can cause problems like this? If we have more things to "persist", we will have a bigger client session, combined with many clients all the time in a tiny "server" like that: BUM! what do you think? Thanks in advance! 2008/6/13 9902468 <[EMAIL PROTECTED]>: > > Hi, > > We had same symptoms with 5.5.25 using T4 during _development_. Our case was > identified that the live class loading resulted in that error once the app > got big enough. The live reloading is somewhat broken anyway in Tomcat, so > we moved to Glassfish in our next project as the development server. The > experience has been better with Glassfish, it takes longer to initially > start, but feels faster once up & live reloading works better -> not so much > need to restart all the time. > > Haven't had single issue in production (In production we use JBoss.). > > - 99 > > > Estevam Henrique Portela Mota e Silva wrote: >> >> Good Afternoon, >> >> Who knows the problem of tomcat on the server. >> >> Tomcat's war have 17 in my company >> Memory (Initial memory pool: 512mb and Maximum memory pool: 1024mb) >> Version: >> --> Tomcat 5.5.26 >> --> JDK 6_05 >> Server: >> --> Gigabyte, Core 2 Duo and Memory 2 gb (motherboard has maximum of >> memory is 2 gb) >> Added: >> --> Isapi Redirector 1.2.14 on another server (IIS 5.0 and Win 2000) >> Note: >> --> All programs are installed executable (EXE) >> >> When I clicked generate PDF (Jasper) in my project, was wrong ... See >> below >> pra >> >> [ERROR] RequestExceptionHandler Processing of request failed with uncaught >> exception: PermGen space >> java.lang.OutOfMemoryError: PermGen Space >> >> How resolved? >> >> -- >> Regards, >> >> Estevam Henrique Portela Mota e Silva >> Handicapped Auditory = deaf >> [EMAIL PROTECTED] / [EMAIL PROTECTED] >> Programmer Java and Tapestry >> Brazil - Fortaleza / CE >> >> > > -- > View this message in context: http://www.nabble.com/Tomcat-5.5.26-%2B-JDK-6_05---java.lang.OutOfMemoryError%3A-PermGen-Space-tp17804956p17816332.html > Sent from the Tapestry - User mailing list archive at Nabble.com. > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Atenciosamente, Marcelo Lotif --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
