tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tolles, James" <James_Tol...@mpaa.org>
Subject RE: Memory leak with ThreadGroups
Date Thu, 23 Jan 2003 23:23:05 GMT
I've noticed this when using jswat debugger. Each time we use the manager app to reload and
updated class, we can see a new instace of the class in the jswat class list - each as a extra
little number assigned to it. Its beyond my skill level but is seems odd that there can be
two instances of the exact same class loaded in the VM? My guess is that the classloader loads
in a new instance that is used but the previous one is still in the vm - not sure how this
is possible.



-----Original Message-----
From: Craig R. McClanahan [mailto:craigmcc@apache.org]
Sent: Thursday, January 23, 2003 3:15 PM
To: Tomcat Users List
Subject: Re: Memory leak with ThreadGroups




On Thu, 23 Jan 2003, Joseph Shraibman wrote:

> Date: Thu, 23 Jan 2003 16:58:28 -0500
> From: Joseph Shraibman <jks@selectacast.net>
> Reply-To: Tomcat Users List <tomcat-user@jakarta.apache.org>
> To: tomcat-user@jakarta.apache.org
> Subject: Memory leak with ThreadGroups
>
> One of my classes creates a static ThreadGroup.  I notice that when I
> update a class and tomcat reloads that context the ThreadGroup is still
> around. If the ThreadGroup is still around that means the old class is
> still around, which means that class loader is still around.  Why is it
> still around?  I tried making the ThreadGroup daemon but it didn't help.
>
> I think the fact that the old class loaders are still around goes a long
> way to explaining why tomcat takes up so much memory.
>

If your application creates new threads (and/or thread groups), then it's
*your* problem to cleam them up when the application shuts down, not
Tomcat's.  Tomcat is only responsible for cleaning up its own threads.

A very easy way to deal with this is create a ServletContextListener and
clean up all your application threads in the contextDestroyed() method.

Craig


--
To unsubscribe, e-mail:   <mailto:tomcat-user-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:tomcat-user-help@jakarta.apache.org>


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message