[
https://issues.jboss.org/browse/WFLY-967?page=com.atlassian.jira.plugin.s...
]
Stan Silvert commented on WFLY-967:
-----------------------------------
Vlad, what problem are you actually seeing due to this (possible) leak?
I'm seeing the Managed Bean "Test" sometimes stick around because it is
request-scoped bean and it is referenced by the HttpServletRequestImpl. Those do get
cleaned up and/or recycled so I can't say that the bean is really leaking.
Before you were talking about the ModuleClassLoader. Do you have some procedure that
causes lots of those instances that get created but never cleaned up?
It would be easy enough to call Introspector.flushCaches on undeploy of JSF apps but I
don't want to do it if I can't see a compelling reason.
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