RE: memory leak on context reload or stop/start? [was Re: tracking memory usage over time]
Howdy, Can you elaborate on your findings regarding log4j's memory leak? A new thread might be better for this. Thanks, Yoav Shapira Millennium ChemInformatics -Original Message- From: Aditya [mailto:[EMAIL PROTECTED] Sent: Thursday, March 13, 2003 11:58 PM To: Tomcat Developers List Subject: memory leak on context reload or stop/start? [was Re: tracking memory usage over time] Just to followup, we have found a few things that were causing this leak, two that were particular to our setup, but the third seems to be a Tomcat problem (4.1.20 with Jasper2): 1) log4j was eating up a lot of memory and there was a slow leak. Since it wasn't strictly required, we've stopped using it and the largest leak stopped. 2) we are using jdbcpool from http://www.bitmechanic.com/projects/jdbcpool/ (it is the only connection pool we could find that can be instantiated programmatically from within a context without having to define a pool in advance via JDNI -- we give each context it's own database and therefore it's own pool) which doesn't seem to have a clean way to stop the pool manager thread when a context is stopped/reloaded. We've worked around this, however the memory leak remains and is due to context reloads / stops-starts 3) there seems to be a leak caused by reloading or stopping/starting a context (we have an automatic httpunit test that builds a jar file periodically and makes sure it is working in a context). We don't see the memory leak unless one or more JSPs are compiled before the context is reloaded or stopped/started. Is there some particular section of the code we should be examining to track this further? Adi On Tue, 25 Feb 2003 22:08:41 -0600, Glenn Nielsen [EMAIL PROTECTED] said: Aditya wrote: Glenn, several months ago you had posted a URL to a document (at kinetic.more.net if I remember correctly) where you talked about having to restart your production Tomcat(s) every 4 weeks or so due to Heap exhaustion. Is that still the case? If so what causes the heap exhaustion? I think that part of the heap problem for me was the recent bug in Jasper which I fixed where a number of resources such as Node trees from a JSP page compile were not dereferenced between compiles. This was fixed in Jasper before the 4.1.20 release. We've looked high and low, with JProbe etc, and we still can't find where the leak is. We're having to restart a Tomcat (4.1.20) with -Xms and -Xmx both set to 256M every 4 days or so. Does the increase in memory usage correlate with an increased number of connectors due to a spike in request volume? Perhaps you should try increasing the heap size. Regards, Glenn - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: memory leak on context reload or stop/start? [was Re: tracking memory usage over time]
The release note of Tomcat 4.1.18 talks about a known memory leak with JSPs. I am not aware of its status with Tomcat 4.1.20. This is what it has to say, JAVAC leaking memory: The Java compiler leaks memory each time a class is compiled. Web applications containing hundreds of JSP files may as a result trigger out of memory errors once a significant number of pages have been accessed. The memory can only be freed by stopping Tomcat and then restarting it. The JSP command line compiler (JSPC) can also be used to precompile the JSPs. -- Uddhav - Original Message - From: Aditya [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Friday, March 14, 2003 10:27 AM Subject: memory leak on context reload or stop/start? [was Re: tracking memory usage over time] Just to followup, we have found a few things that were causing this leak, two that were particular to our setup, but the third seems to be a Tomcat problem (4.1.20 with Jasper2): 1) log4j was eating up a lot of memory and there was a slow leak. Since it wasn't strictly required, we've stopped using it and the largest leak stopped. 2) we are using jdbcpool from http://www.bitmechanic.com/projects/jdbcpool/ (it is the only connection pool we could find that can be instantiated programmatically from within a context without having to define a pool in advance via JDNI -- we give each context it's own database and therefore it's own pool) which doesn't seem to have a clean way to stop the pool manager thread when a context is stopped/reloaded. We've worked around this, however the memory leak remains and is due to context reloads / stops-starts 3) there seems to be a leak caused by reloading or stopping/starting a context (we have an automatic httpunit test that builds a jar file periodically and makes sure it is working in a context). We don't see the memory leak unless one or more JSPs are compiled before the context is reloaded or stopped/started. Is there some particular section of the code we should be examining to track this further? Adi On Tue, 25 Feb 2003 22:08:41 -0600, Glenn Nielsen [EMAIL PROTECTED] said: Aditya wrote: Glenn, several months ago you had posted a URL to a document (at kinetic.more.net if I remember correctly) where you talked about having to restart your production Tomcat(s) every 4 weeks or so due to Heap exhaustion. Is that still the case? If so what causes the heap exhaustion? I think that part of the heap problem for me was the recent bug in Jasper which I fixed where a number of resources such as Node trees from a JSP page compile were not dereferenced between compiles. This was fixed in Jasper before the 4.1.20 release. We've looked high and low, with JProbe etc, and we still can't find where the leak is. We're having to restart a Tomcat (4.1.20) with -Xms and -Xmx both set to 256M every 4 days or so. Does the increase in memory usage correlate with an increased number of connectors due to a spike in request volume? Perhaps you should try increasing the heap size. Regards, Glenn - 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]
