We are using 4.1.20 where this particular leak (and another one in Jasper) is supposed to be fixed and we use jikes in any case.
Thanks, Adi > On Fri, 14 Mar 2003 10:51:57 +0530, "Uddhav Shirname" <[EMAIL PROTECTED]> said: > 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]
