tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Cox, Charlie" <c...@cincom.com>
Subject RE: Memory leak with ThreadGroups -> and other stuff
Date Fri, 24 Jan 2003 14:18:59 GMT


> -----Original Message-----
> From: Chris Brown [mailto:brown2@reflexe.fr]
> Sent: Friday, January 24, 2003 4:55 AM
> To: Tomcat Users List
> Subject: Re: Memory leak with ThreadGroups -> and other stuff
> 
> 
> Quick follow-on question for Craig...
> 
> If you put a JDBC driver in your webapp's /WEB-INF/lib 
> directory, then as
> that gets registered with DriverManager, what happens when 
> you reload a
> context?  If the DriverManager maintains a reference to the 
> Driver loaded
> with the webapp classloader, that must surely cause a few problems for
> cleaning up the classloader...
> 

When you reload the context, the webapp classloader and all its classes are
discarded. Once a new classloader is created, it can not access the previous
instance, so you will end up with ClassCastExceptions. Your old classloader
will NOT be gc'ed until that reference is released.

> Should this sort of problem disappear with
> "DriverManager.deregisterDriver()" ?  Are there other 
> pitfalls of this sort
> in the standard Java APIs (I'm thinking of some classes with 
> factory methods
> and "helpful" internal caching of instances created via such factory
> methods...)
> 

I have never used DriverManager.deregisterDriver(), but I would think that
it would help. I have always had my database drivers in /common/lib so that
they are only loaded once.

if want you share your factory instances between webapps, put them in
/common/lib. If you want each webapp to have its own instance of your
factory methods and thus their own instances, then put them in WEB-INF/lib.

The only other issue that I have run into with the web app classloader is
when using System.loadLibrary() to load an external class. This causes a
problem becuase the library is loaded by the JVM and the class instances are
created by the classloader, so when you reload, you lose the instances and
can't reload the library since the JVM already thinks its loaded. I got
around this by leaving this code in /common/lib so it is only loaded once
and shared among all webapps.

Charlie

> - Chris
> 
> ----- Original Message -----
> From: "Craig R. McClanahan" <craigmcc@apache.org>
> Sent: Friday, January 24, 2003 1:49 AM
> Subject: RE: Memory leak with ThreadGroups
> 
> > 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.
> 
> 
> 
> 
> --
> To unsubscribe, e-mail:   
<mailto:tomcat-user-unsubscribe@jakarta.apache.org>
For additional commands, e-mail:
<mailto:tomcat-user-help@jakarta.apache.org>

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


Mime
View raw message