commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Attila Szegedi" <szege...@freemail.hu>
Subject [pool] Evictor thread
Date Tue, 08 Feb 2005 13:26:00 GMT
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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message