tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tolles, James" <>
Subject RE: Memory leak with ThreadGroups
Date Fri, 24 Jan 2003 18:24:56 GMT
Thank-you for the reply.

I have 4 java certifications but it seems like there has been little emphasis on class loaders
which are actually very, very important.

Could I ask another question? 

It seems like re-loading a new jsp workw easily and well, only the new jsp gets loaded, the
application is not restarted. But, if a servelt is updated, Tomcat (if reload is on) begins
a sequence: tries to serialize the session adn save it; reloads the app; then restore the
session. Is it a class loader issue that prevents tomcat from treating the new servlet class
tha same as a new jsp?

-----Original Message-----
From: Craig R. McClanahan []
Sent: Thursday, January 23, 2003 4:49 PM
To: Tomcat Users List
Subject: RE: Memory leak with ThreadGroups

On Thu, 23 Jan 2003, Tolles, James wrote:

> Date: Thu, 23 Jan 2003 15:23:05 -0800
> From: "Tolles, James" <>
> Reply-To: Tomcat Users List <>
> To: 'Tomcat Users List' <>
> Subject: RE: Memory leak with ThreadGroups
> 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.

Classes have to be unique only within a class loader hierarchy, not
JVM-wide.  For instance, it's perfectly reasonable for two different
webapps to have a class named com.mycompany.mypackage.Foo, even if those
classes are totally different.

Java does not provide any way to remove a previously loaded class from a
class loader.  The only way to implement webapp reloading, then, is to
have Tomcat throw away its reference to the webapp class loader and create
a new one.

If your application is well behaved (i.e. it doesn't have classes in
common/lib or shared/lib that maintain references to things loaded from
the webapp), then this will cause the entire webapp to become garbage.  If
*any* references to *any* classes inside the webapp still exist, though,
then essentially nothing from your webapp can be collected.

Of course, this should only be an issue during development -- you should
not use auto-reloading in a production environment.


To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

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