geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dain Sundstrom <>
Subject Re: Memory leaks
Date Sun, 05 Jun 2005 02:13:50 GMT
After poking around the commons logging 1.0.4 code, it looks like I  
can explicitly release a class loader from the hashtable, so I'm  
going to take a crack at getting our class loaders to GC.


On Jun 4, 2005, at 6:46 PM, Dain Sundstrom wrote:

> The other day I started to see OutOfMemory errors, so after a few  
> hours of poking around with YourKit, I found the two big leaks.
> The first one I found was caused by the GBean reference object  
> registering a listener with the lifecycle monitor and never  
> unregistering it.  Since the reference holds on the the  
> GBeanInstance we never could collect a GBeanInstance that had a  
> reference (most do).  This doesn't mean we were leaking instance of  
> the actual service objects, but the GBeanInstance object does hold  
> on to a lot of data.
> The second leak we have is a leak of class loaders due to the  
> following two causes:
> 1) Commons logging 1.0.4
> The LogFactory retains a hard reference to the class loader.  I  
> believe this has been addressed in the next version which is  
> version just in alpha now.
> 2) Context class loader of a pooled thread
> We need to clear the context class loader before putting threads  
> back in a pool.  The context class loader should always be cleared  
> after being set in a try/finally block, but in some cases they are  
> not.  BTW, this is not always a pool, the sun orb keeps a hard  
> reference to a thread it uses for reading from a socket.
> I don't fix the class loader leak right now (due to commons  
> logging), but we should at least start to clear the context when  
> reinsert a into a pool.
> -dain

View raw message