openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Prud'hommeaux <mprud...@apache.org>
Subject Re: PCRegistry ClassLoader memory leak
Date Mon, 16 Jul 2007 21:40:58 GMT
Kevan-

How many deploy/undeploys does it take before it runs out of memory?

I recall a long time back we had a similar problem (although the  
error was entrenched in the same functionality contained in the  
javax.jdo.spi.JDOImplHelper. I don't know if a solution was ever  
found. Short of figuring out some way to listen for the death of a  
ClassLoader and manually unregistering metadata when that happens, I  
can't think of any way to deal with this automatically.

Anyone have any ideas?



On Jul 16, 2007, at 2:31 PM, Kevan Miller wrote:

> Geronimo is running out of PermGen space in some simple deploy/ 
> undeploy scenarios involving OpenJPA. The cause of the problem  
> seems to be the _metas table in PCRegistry. _metas is a  
> ConcurrentReferenceHashMap with WEAK reference keys and HARD  
> reference values. The keys are the PersistenceCapable classes.  
> While the values are the metadata for these classes which are  
> maintained by the internal Meta class.
>
> The cause of the ClassLoader memory leak is simple -- if any of the  
> objects/classes held by the Meta class (e.g. fieldTypes) have also  
> been loaded by the same ClassLoader used to load the  
> PersistenceCapable class, the PersistenceCapable class (the weak  
> key) will never be GCed. The value of the HashMap entry will always  
> maintain a hard reference to the ClassLoader. Since the ClassLoader  
> will never be GC'ed, the the the pcClass Class object will never be  
> GC'able...
>
> The problem can be easily recreated using current Geronimo trunk  
> and the Geronimo Daytrader application.
>
> --kevan


Mime
View raw message