[jboss-jira] [JBoss JIRA] (WFLY-10991) Memory leak when deployment is redeployed multiple times

[Jan Stourac (JIRA)]

Jan Stourac created WFLY-10991:
----------------------------------

             Summary: Memory leak when deployment is redeployed multiple times
                 Key: WFLY-10991
                 URL: https://issues.jboss.org/browse/WFLY-10991
             Project: WildFly
          Issue Type: Bug
          Components: MP OpenTracing
    Affects Versions: 14.0.0.Beta2
            Reporter: Jan Stourac
            Assignee: Juraci Paixão Kröhling
            Priority: Critical
         Attachments: memoryLeaks.war, problematic-wf-build-heap-diff-start-end-org-filter.png, problematic-wf-build-heap-diff-start-end.png, sane-wf-build-heap-diff-start-end-org-filter.png, sane-wf-build-heap-diff-start-end.png

It looks like redeploying attached deployment [^memoryLeaks.war] multiple times (our automated test does it 100 times), there seems to be some memory leak in the WildFly. Using git bisect, the commit that started to fail is [651dc8a2f0d4ccad6a35f7b1d28626b43ebb2a5d in WildFly repository|https://github.com/wildfly/wildfly/commits/651dc8a2f0d4ccad6a35f7b1d28626b43ebb2a5d]. That is why I selected MP OpenTracing component for this issue.

Brief description of the test:
# attached deployment is deployed
# System.gc() is called via EJB call
# it checks initial heap usage at the beginning of the test via EJB call that checks all instances of ManagementFactory.getMemoryPoolMXBeans()
# deployment is redeployed 100 times
# calls System.gc() via EJP call again and checks heap usage again via EJB call and compares the results

I tried to check manually via [visualVM|https://visualvm.github.io/] tool. You can create a heapdump at the beginning of the test and at the end of the test. Then compare them easily and check the differences. Using a filter I can see quite a huge increase of instances of the {{org.jboss.modules.*}} classes. However, biggest memory footprint is huge increase of the instances of the {{java.util.HashMap$Node}}, {{char[]}}, {{java.util.HashMap$Node[]}} and few others. I don't see such huge increase of the instances of these classes when I use older build of WildFly prior to the problematic commit. To be honest I don't see direct link with the problematic commit I linked before. As the heapdumps are too big to be attached here, I am attaching some screenshots.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)