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.
-dain
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
