geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Donald Woods <dwo...@apache.org>
Subject Re: [jira] Updated: (GERONIMO-3326) ClassLoader memory leak caused by OpenJPA
Date Mon, 30 Jul 2007 12:07:00 GMT
Kevan, is there an associated OpenJPA JIRA for this, so we can track its progress?


-Donald

Kevan Miller (JIRA) wrote:
>      [ https://issues.apache.org/jira/browse/GERONIMO-3326?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
> 
> Kevan Miller updated GERONIMO-3326:
> -----------------------------------
> 
>     Attachment: OpenJPAMemLeak-G.patch
>                 OpenJPAMemLeak-OJPA.patch
> 
> I'm attaching patches for both OpenJPA and Geronimo that fixes the problem. 
> 
> Will need to work with the OpenJPA community to get the OpenJPA patch applied.
> 
> With this patch basic deploy/undeploy of DayTrader is much better. I've run over 350
deploy/undeploys. There may be a bit of memory growth. Without profiling, it's hard to tell.
For infrequent operations like deploy/undeploy, I'd say things look very good...
> 
> I've only deployed/undeployed DT. Would be good to try DT operations in between deploy/undeploy...
> 
>> ClassLoader memory leak caused by OpenJPA
>> -----------------------------------------
>>
>>                 Key: GERONIMO-3326
>>                 URL: https://issues.apache.org/jira/browse/GERONIMO-3326
>>             Project: Geronimo
>>          Issue Type: Bug
>>      Security Level: public(Regular issues) 
>>          Components: persistence
>>    Affects Versions: 2.0-M7
>>            Reporter: Kevan Miller
>>            Assignee: Kevan Miller
>>            Priority: Critical
>>             Fix For: 2.0
>>
>>         Attachments: OpenJPAMemLeak-G.patch, OpenJPAMemLeak-OJPA.patch
>>
>>
>> As David Jencks mentioned in GERONIMO-3305, there's a ClassLoader memory leak in
deploy/undeploy. 
>> 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.
>> FYI, here are the GC Roots for one of our ClassLoaders being leaked -- http://people.apache.org/~kevan/PCRegistryLeak.html
>> I've contacted the OpenJPA dev list. Hopefully, can get this resolved, quickly.
> 

Mime
View raw message