Hi,
this problem is common to Tomcat, as the problem is in the classloader, some
thoughts about this can be found at
http://www.patrickpeak.com/page/patrick/20050614#your_web_app_is_leaking
Cheers,
Markus
> 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]
