[
https://issues.apache.org/jira/browse/OPENJPA-746?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tim McConnell reassigned OPENJPA-746:
-------------------------------------
Assignee: Tim McConnell
> Possible memory leak involving MappingRepository
> ------------------------------------------------
>
> Key: OPENJPA-746
> URL: https://issues.apache.org/jira/browse/OPENJPA-746
> Project: OpenJPA
> Issue Type: Bug
> Affects Versions: 1.2.0
> Reporter: Patrick Peck
> Assignee: Tim McConnell
>
> We are using OpenJPA with Derby in our application. In our functional test
> suite (using TestNG), we
> repeatedly create a new Derby database and access it using an OpenJPA
> EntityManager. The number
> of classes and tables is less than 10, but after about 100-200 create/destroy
> cycles, the VM runs
> out of heap.
> I tried to track down the cause of the leak, and one possible cause seems to
> be the MappingRepository
> class whose instance count kept increasing, while other "suspects"
> (BrokerImpl, EntityManagerImpl,
> EntityManagerFactoryImpl,...) had a constant instance count. Because of the
> latter, I am pretty sure that the
> test suite itself does not hold on to OpenJPA instances longer than needed,
> so I suspect a memory leak within
> OpenJPA itself. What exactly keeps the MappingRepository instances from being
> GC'd, I wasn't able to
> analyse given the time available and the complex reference graph that this
> class is involved in.
> P.S.:
> I googled for OpenJPA memory leaks, and the only memory leak issue I came
> across was the one
> involving multiple redeployments in Geronimo and ClassLoader leaks.
> This issue is different, because OpenJPA always runs in the same classloader.
> I looked into the
> "PCRegistry._metas" static field, and the number of entries remained
> constant. So I suspect that
> the reason for the leak is somewhere else.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
