[
https://issues.apache.org/jira/browse/OPENJPA-746?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12729515#action_12729515
]
Michael Dick commented on OPENJPA-746:
--------------------------------------
Could you describe the domain model, or provide persistence.xml?
I'd think that there's something unique about this test environment, otherwise
we'd see this in SpecJAppServer, or DayTrader runs in JEE environments..
> 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
> Attachments: screenshot-1.jpg
>
>
> 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.
