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
