openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rick Curtis (JIRA)" <>
Subject [jira] Closed: (OPENJPA-746) Possible memory leak involving MappingRepository
Date Wed, 22 Sep 2010 15:10:35 GMT


Rick Curtis closed OPENJPA-746.

      Assignee:     (was: Tim McConnell)
    Resolution: Cannot Reproduce

As Mike stated  "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.. " I second that statement.

I'm going to close this issue as there hasn't been any activity in quite a long time. Please
reopen if you can reproduce this issue and have some cycles the spend on the debug effort.

> Possible memory leak involving MappingRepository
> ------------------------------------------------
>                 Key: OPENJPA-746
>                 URL:
>             Project: OpenJPA
>          Issue Type: Bug
>    Affects Versions: 1.2.0
>            Reporter: Patrick Peck
>         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
> 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
> 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.

View raw message