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]

Reply via email to