[
https://issues.jboss.org/browse/WFLY-967?page=com.atlassian.jira.plugin.s...
]
Vlad Arkhipov commented on WFLY-967:
------------------------------------
The problem turns up in development mainly, but it also makes you to increase PermGen on
production systems.
I see a new ModuleClassLoader in the heap dump for each deploy/undeploy of war-leak.war.
There are no live paths to these class loaders, however they are collected by GC only
after 30 minutes.
I think Introspector.flushCaches is not a good solution here, it's just a workaround,
because it affects other deployments on the same server. In
com.sun.faces.util.ReflectionUtils.clearCache it is possible to properly remove from
Introspector only classes, that relates to the currently undeploying application.
ClassLoader memory leak with JSF
--------------------------------
Key: WFLY-967
URL:
https://issues.jboss.org/browse/WFLY-967
Project: WildFly
Issue Type: Bug
Components: JSF
Reporter: Vlad Arkhipov
Assignee: Stan Silvert
Priority: Critical
Attachments: war-leak.tar.gz
JSF application's classes are not unloaded properly when undeployed. The test case is
in the attachment. Steps to reproduce:
# mvn package
# deploy war-leak.war
# open
http://localhost:8080/war-leak
# undeploy war-leak.war
# analyze a heap dump to find unloaded ModuleClassLoader of war-leak.war
References to the WAR classes are hold by java.beans.Introspector caches. It seems to be
a known bug (feature?). For example Tomcat automatically invokes
java.beans.Introspector.flushCaches() when WAR undeploys. There is also
IntrospectorCleanupListener in Spring for the same purpose.
http://wiki.apache.org/commons/Logging/UndeployMemoryLeak
http://static.springsource.org/spring/docs/2.5.x/api/org/springframework/...
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see:
http://www.atlassian.com/software/jira