[
https://issues.jboss.org/browse/WFLY-6173?page=com.atlassian.jira.plugin....
]
jaikiran pai commented on WFLY-6173:
------------------------------------
Just had a quick look. This is reproducible against latest WildFly upstream code too. This
appears to be a bug in the weld integration deployment process in the WildFly code.
There's the org.jboss.as.weld.WeldModuleResourceLoader to which application classes
get added but never get removed from that resource loader. The WeldModuleResourceLoader in
itself get held on through some other integration classes like the WeldDeployment which
goes all the way to the Weld implementation's service registry.
I think this is something that either [~jharting] or [~swd847] might be able to help with.
Building, deploying and accessing the attached application from a browser and then
undeploying it, easily reproduces the problem. I then did a jmap dump and used jhat to
find the references.
Classes not unloaded after undeployment
---------------------------------------
Key: WFLY-6173
URL:
https://issues.jboss.org/browse/WFLY-6173
Project: WildFly
Issue Type: Bug
Components: CDI / Weld
Affects Versions: 8.2.0.Final, 10.0.0.Final
Reporter: Joey Wang
Assignee: Jason Greene
Attachments: memory-leak.zip
I deployed a small web application with one single JSF and one managed bean, accessed the
page and then undeployed the application. I found the classes of this application had
never been unloaded via monitoring with Java VistualVM, also using
'-XX:+TraceClassUnloading' JVM option proved the classes not unloaded.
Then checking the heap dump of it, I found there were instance for each enum item (the
managed bean has one enum type field, which is always initialized when the managed bean
constructed) and one array instance including these enum instances.
Please refer to the attachment for the same application. I started to verify the
classloader memory leak issue because we found hot redeployment of our real application
swallow some memory each time, then after lots of redeployment the server was short of
memories.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)