[
https://issues.apache.org/jira/browse/OPENJPA-285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12517094
]
Kevin Sutter commented on OPENJPA-285:
--------------------------------------
Also, the two other patches attached to this Issue (JIRA-285.patch.txt and
JIRA-285.patch.2.txt) are not being included in this commit processing.
Neither of these were deemed to resolve the problem as originally reported.
> Multiple deploy/undeploy leaks memory in PCRegistry
> ---------------------------------------------------
>
> Key: OPENJPA-285
> URL: https://issues.apache.org/jira/browse/OPENJPA-285
> Project: OpenJPA
> Issue Type: Bug
> Components: kernel
> Affects Versions: 1.0.0
> Environment: Geronimo 2.0
> Reporter: Pinaki Poddar
> Assignee: Kevin Sutter
> Fix For: 1.0.0
>
> Attachments: ImplHelperClassLoaderMemoryLeak.patch,
> JIRA-285.patch.2.txt, JIRA-285.patch.txt,
> PCRegistryClassLoaderMemoryLeak.patch
>
>
> Kevin Miller reported:
> 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.
> Patrick Linskey suggested:
> Change PCRegistry.fieldTypes to be String[] instead of Class[], and
> dematerialize them as needed.
> Robert Burrell Donkin/Marc Prud'hommeaux both pointed out that alternatives
> such as to
> listen for the death of a ClassLoader and manually unregistering metadata
> would be more costly in terms of complexity.
> This patch follows Patrick's suggestion.
> 1. Changes the Meta.fieldTypes to String[] from Class[]
> 2. Adapts the enhanced bytecode accordingly to the modified method signatures
> 3. PCRegistry getFieldTypes() load the fields' declared type using the same
> loader that loaded the owner pc class.
> Note: For a class C and its field f, CL(c) == CL(f) is not always true.
> (Kevin Miller)
> But CL(c) will be able to load declared type of f either directly
> or via one of its parent (Craig Russel)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
