openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Patrick Peck (JIRA)" <>
Subject [jira] Created: (OPENJPA-746) Possible memory leak involving MappingRepository
Date Tue, 14 Oct 2008 17:41:44 GMT
Possible memory leak involving MappingRepository

                 Key: OPENJPA-746
             Project: OpenJPA
          Issue Type: Bug
    Affects Versions: 1.2.0
            Reporter: Patrick Peck

We are using OpenJPA with Derby in our application. In our functional test suite (using TestNG),
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

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