Hi all,
I've just been through a particularly nasty case of debugging a memory leak where the evictor thread of GenericObjectPool (as used by DBCP) was not willing to die and let go of a disposed ClassLoader it held as the loader of a ProtectionDomain of its inherited SecurityContext. Now, while GenericObjectPool.close() was being called, the Thread running the Evictor code didn't observe the change in the _cancelled flag. This is unfortunately perfectly legal under the Java memory model given that there is neither a synchronization surrounding reading and writing of the flag, nor a volatile flag on the _cancelled flag.
So, I'd ask you to fix this by adding the "volatile" flag to the "boolean _cancelled" field of the org.apache.commons.pool.impl.GenericObjectPool$Evictor class.
Also, it'd be a big improvement in terms of scalability if the GenericObjectPool held a reference to the Thread running the Evictor object, and would interrupt() it on close(), so it doesn't take "timeBetweenEvictionRunsMillis" after a call to close() before the thread actually clears up.
(All this might not be visible in a more-or-less statical environment, but is a problem in a system that frequently reloads classes using new class loaders which are a subclass of java.security.SecureClassLoader and therefore "decorate" threads with security contexts that ultimately hold a reference to the class loader. Few loitering class loaders can quickly escalate into an OutOfMemoryError.)
Thanks, Attila
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
