Anyone have any ideas?
Change fieldTypes to be Strings instead, and dematerialize them as needed. -Patrick On 7/16/07, Marc Prud'hommeaux <[EMAIL PROTECTED]> wrote:
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
-- Patrick Linskey 202 669 5907
