[jira] Updated: (OPENJPA-746) Possible memory leak involving MappingRepository

["brian yoder (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/OPENJPA-746?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

brian yoder updated OPENJPA-746:
--------------------------------

    Attachment: screenshot-1.jpg

> 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.