openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tim McConnell (JIRA)" <j...@apache.org>
Subject [jira] Assigned: (OPENJPA-746) Possible memory leak involving MappingRepository
Date Sun, 17 May 2009 03:11:45 GMT

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


Mime
View raw message