[
https://issues.jboss.org/browse/WFLY-967?page=com.atlassian.jira.plugin.s...
]
Stan Silvert commented on WFLY-967:
-----------------------------------
I'm not seeing an actual leak. The instances do go away eventually. It looks like
something is timing out after 30 minutes, which makes these instances eligible for GC.
That made me thing it had something to do with session timeout. But I'm not sure at
this point. When I tried setting session timeout to a lower value, I found a bug in
Undertow, UNDERTOW-42.
Can you try to replicate my results on your end?
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