Hello, I've also run into this problem during development AND on our live production environment. We have a production server which we run Tomcat on. The different web applications share the same JVM. This is because we don't have infinite hardware, else we would have had more servers and one JVM per site. Now, when we want to update a site, we simply stop the web application (in tomcat's manager), deploy the new JAR's and other files, start the application and it's running again without the other sites being interupted. If we do this too many times, we get an OOME. I understand that this is not a Tapestry bug, but maybe someone can share some thoughts on how to fix this?
Thanks, Niklas -----Ursprungligt meddelande----- Från: Michael Musson [mailto:[EMAIL PROTECTED] Skickat: den 21 juni 2005 07:37 Till: Tapestry users Kopia: Tomas Jucius Ämne: Re: HUGE BUG - MEMORY LEAK IN TAPESTRY 3.0.3!!! - PLEASE SUPPORT On 6/17/05, Tomas Jucius <[EMAIL PROTECTED]> wrote: > But after a lot of resets jvm memory becomes full, and I get > "java.lang.OutOfMemoryError" This issue has been raised in a previous thread. It was found that setting the property disable-caching to true would eventually lead to an out of memory exception and that setting the property to false would prevent the exception from occurring. However since you are calling the reset service you are creating the same situation through different means. Here is Johan's original message below summarizing what he found: When I looked at this in Jan 31 (see archives) the error I ran into was an OOME. When I looked at the actual stack-trace I could see that it was the permanent heap that was out of memory. This is significant since the permanent heap is used for storing classes and types. I have never seen a profiler that analyses the permanent heap in detail - it would be interesting to know if someone knows if such a tool exists. The permanent heap is most probably never garbage collected, this would amount to throwing away class definitions. This is usually not a problem since an ordinary application has a finite number of classes defined and when they are loaded that is it. Now, when in development mode I assume, and this is just a guess, that Tapestry is enhancing and creating _new_ classes every time a page is loaded. This will fill the permanent heap after a while and when that is full you'll get OOME. When Tapestry can cache the classes it creates the permanent heap will not fill up with new classes and everything should work as expected. So this will only be a problem when in development mode, I wouldn't even consider it a bug in Tapestry (this can happen with JSP compilers also), merely a fact of life as a developer :-) --------------------------------------------------------------------- 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]
