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:[EMAIL PROTECTED]] 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 <[EMAIL PROTECTED]> > Reply-To: Tomcat Users List <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > 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:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
