[
https://issues.apache.org/jira/browse/MYFACES-3510?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13236689#comment-13236689
]
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: https://issues.apache.org/jira/browse/MYFACES-3510
> 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:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
