Cedric Tabin created OPENJPA-2454:
-------------------------------------
Summary: Memory leak when using multiple classloaders
Key: OPENJPA-2454
URL: https://issues.apache.org/jira/browse/OPENJPA-2454
Project: OpenJPA
Issue Type: Bug
Affects Versions: 2.2.2
Environment: Java EE6 with Glassfish 3.1.2.2, MySQL 5.1, VisualVM
1.3.6, Linux Gentoo
Reporter: Cedric Tabin
Priority: Minor
Hello,
When entities are retrieved from a class loaded dynamically (ie by a [new]
ClassLoader), OpenJPA will trigger a memory leak that will prevent the JVM to
GC the loaded classes.
An simple example can be easily reproduced and is available here:
http://www.astorm.ch/blog/public/Sources/classloader-leak-ee.zip
All the explanations are provided in the README.
The main steps are the following:
1) When a query comes, create a new ClassLoader (see
ch.astorm.ejb.facade.EntryPointBean and ch.astorm.ejb.system.ClassLoaderManager)
2) Load dynamically a new instance of a class in the ClassLoader of step (1).
This class should not be included in the EJB (see
ch.astorm.apis.SimpleProcessor).
3) Invoke a method on it that will retrieve some data, using JPA (a
getResultList) injecting the arguments directly in the query string (not using
the Query.setParameter method).
In the sample project provided, there are 8 queries asking for one instance of
Person each. The class asked to do this job is ch.astorm.apis.SimpleProcessor
which extends ch.astorm.ejb.system.AbstractProcessor (actually doing the job).
One over two of thoses requests asks to reset the classloader (ie to drop all
the current loaded classes and create a new one).
After thoses requests, if one looks in a heap dump, he will see 4 instances of
MyClassLoader (which is an internal class of
ch.astorm.ejb.system.ClassLoaderManager). Of course there should be only one
instance of the latter...
What is surprisingly weird is that 3 of those instances have no GC root,
meaning they *should* be collected but actually never will, even if the PermGen
space is full.
It looks like a bug in the JVM, but if the JPA implementation is changed to
EclipseLink in the persistence.xml, then there is no more leak. That drives me
to say that OpenJPA could make something the JVM doesn't like...
The problem arises on Linux/Windows, Glassfish-3.1.2.2/Weblogic-12c,
MySQL/Oracle.
Thansk for your help !
--
This message was sent by Atlassian JIRA
(v6.1#6144)
