myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ruben Martin Pozo (Commented) (JIRA)" <>
Subject [jira] [Commented] (MYFACES-3510) Application components classloader memory leak
Date Fri, 23 Mar 2012 15:41:27 GMT


Ruben Martin Pozo commented on MYFACES-3510:

I've run the same test with patch2 and the problem keeps happening. The server freezes for
40 seconds in the method TomcatAnnotationLifecycleProvider.isAvailable.

I run a little test. I changed that method to always return false since my application is
running on a glassfish not a tomcat. And magically everything worked!!!. The classloaders
are garbage collected and the server doesn't freeze.

Here is what I think is happening. It might sound science fiction but here it goes:

I'm running with the flag -XX:+UseConcMarkSweepGC so I'm running a concurrent garbage collector.
When there isn't any more room in the permGen for classes, a permGen gc cycle is run. While
running this cycle the method TomcatAnnotationLifecycleProvider.isAvailable is trying to know
if tomcat is available. To do so, it tries to load a tomcat class. But I don't have this class
in my classpath since I'm not running on a tomcat. The JVM looks for the class in the entire
classpath but it doesn't find it there. Then the JVM tries to traverse the classloaders graph
to ask them for the class but it can't do so since there are some classloader being garbage
collected at the same time. So the JVM waits for for concurrent gc to finish and block the
thread until that moment.

For my application I'll apply the patch you've provided plus the modifications to the TomcatAnnotationLifecycleProvider.isAvailable
so the server doesn't freeze.

I understand this issue is not directly related to this bug. It couldn't happen before the
patch because of the OOM, so this patch kind of unveal this issue

Do you want me to open a new bug?. Maybe you could find a different way of detecting the presence
of tomcat 

> Application components classloader memory leak
> ----------------------------------------------
>                 Key: MYFACES-3510
>                 URL:
>             Project: MyFaces Core
>          Issue Type: Bug
>          Components: General
>    Affects Versions: 2.1.6
>         Environment: WIndows Glassfish Embedded
>            Reporter: Ruben Martin Pozo
>            Assignee: Leonardo Uribe
>             Fix For: 2.0.13, 2.1.7
>         Attachments: MYFACES-3510-1.patch, MYFACES-3510-2.patch, screenshot-1.jpg
> We've seen an application classloader memory leak due to the new class javax.faces.component._PropertyDescriptorHolder
class introduced in version 2.1.6
> This class holds a reference to a Method of a component loaded by the application classloader.
The memory leak shows up when the _PropertyDescriptorHolder is stored in the _ComponentAttributesMap
class that is loaded by the system class loader.
> You should use a WeakReference instead of storing the direct reference to the Method

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:!default.jspa
For more information on JIRA, see:


View raw message