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
-XX:+HeapDumpOnOutOfMemoryError"
FYI, here are the GC Roots for one of our ClassLoaders being leaked
-- http://people.apache.org/~kevan/PCRegistryLeak.html
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...
--kevan
