openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Cedric Tabin (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (OPENJPA-2454) Memory leak when using multiple classloaders
Date Sun, 17 Nov 2013 17:31:24 GMT

     [ https://issues.apache.org/jira/browse/OPENJPA-2454?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Cedric Tabin updated OPENJPA-2454:
----------------------------------

    Description: 
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 attached to the ticket. Further 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 !


  was:
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 !



> 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
>         Attachments: classloader-leak-ee.zip
>
>
> 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 attached to the ticket. Further 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)

Mime
View raw message