openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kevan Miller <>
Subject Re: PCRegistry ClassLoader memory leak
Date Tue, 17 Jul 2007 02:00:35 GMT

On Jul 16, 2007, at 5:40 PM, Marc Prud'hommeaux wrote:

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

Hi Marc,
It's application dependent. I think it took about 20 deploy/undeploy  
cycles. We're losing a ClassLoader per deploy/undeploy. Looks like  
for this app each ClassLoader is ~ 1 meg. I was running with an 80meg  
max permgen:

export JAVA_OPTS="-XX:MaxPermSize=80m -verbose:gc -XX:+PrintGCDetails  

FYI, here are the GC Roots for one of our ClassLoaders being leaked  

> 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?

Well, with some increased complexity, you could have WeakReference  
values (have ConcurrentReferenceHashMap permit WeakReference keys and  
WeakReference values (or wrap Meta with a WeakReference before  
inserting into the _metas table).

Define an OpenJPA specific interface for triggering ClassLoader  
events. Either a callback interface or straight method call. The JSF  
specification defined a javax.faces.FactoryFinder.releaseFactories()  
method which can be called during an undeploy.  That's spec-defined  
however. I'd prefer not to go that way, but it's not impossible...


View raw message