openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "brian yoder (JIRA)" <j...@apache.org>
Subject [jira] Commented: (OPENJPA-746) Possible memory leak involving MappingRepository
Date Mon, 06 Jul 2009 23:23:14 GMT

    [ https://issues.apache.org/jira/browse/OPENJPA-746?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12727831#action_12727831
] 

brian yoder commented on OPENJPA-746:
-------------------------------------

I have also reproduced this bug.  I am using WebSphere 6.1.0.25 (runs with OpenJPA 1.0.4).
 The number of instances of org.apache.openjpa.jdbc.meta.MappingRepository grows to 2,846
- and finally our Prod server runs out of "PS Old Gen" memory. 

As stated the reference graph is very complex, but from each MappingRepository instance we
get many other references (to char[], and other types), but this seems to be the root of the
issue.

Is there a way to ensure the MappingRepository instance count doesn't grow?  I tried using
EJB injection (EntityManager, EntityManagerFactory) and still get the same result.

How can it be nobody else is having the same issue?  I am using MS SQL Server as the database
if that matters.

> 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