[jboss-jira] [JBoss JIRA] (WFLY-6173) Classes not unloaded after undeployment

[David Maes (JIRA)]

    [ https://issues.jboss.org/browse/WFLY-6173?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13312730#comment-13312730 ] 

David Maes edited comment on WFLY-6173 at 10/27/16 2:27 AM:
------------------------------------------------------------

Hey [~mkouba],

I have done some investigating and I have a question. I viewed the heap dump off the application. Specifically the class loaders. I included the image of 2 separate heap dumps. The second heap dump is after a redeploy. As you can see a ModuleClassLoader was added but none were removed. Is this normal behaviour or is something fishy going on there.

 !Screen Shot 2016-10-27 at 08.04.12.png|thumbnail!  !Screen Shot 2016-10-27 at 08.15.27.png|thumbnail! 


was (Author: davidmaes):
Hey [~mkouba],

I have done some investigating and I have a question. I viewed the heap dump off the application. Specifically the class loaders. I included the image of 2 separate heap dumps. The second heap dump is after a redeploy. As you can see a ModuleClassLoader was added but none were removed. Is this normal behaviour or is something fishy going on there.

 !Screen Shot 2016-10-27 at 08.04.12.png|thumbnail! 

> 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: Martin Kouba
>            Priority: Blocker
>         Attachments: memory-leak.zip, memory-leak_New.zip, Screen Shot 2016-10-27 at 08.04.12.png, Screen Shot 2016-10-27 at 08.15.27.png
>
>
> 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
(v7.2.2#72004)