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

[James Perkins (Jira)]

     [ https://issues.redhat.com/browse/WFLY-12486?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

James Perkins updated WFLY-12486:
---------------------------------
    Git Pull Request: https://github.com/wildfly/wildfly/pull/12836, https://github.com/wildfly/wildfly/pull/12878  (was: https://github.com/wildfly/wildfly/pull/12836)


> Memory leak in OpenTracing when deployment is redeployed multiple times
> -----------------------------------------------------------------------
>
>                 Key: WFLY-12486
>                 URL: https://issues.redhat.com/browse/WFLY-12486
>             Project: WildFly
>          Issue Type: Bug
>          Components: MP OpenTracing
>    Affects Versions: 17.0.0.Final, 17.0.1.Final, 18.0.1.Final
>            Reporter: Jan Stourac
>            Assignee: Emmanuel Hugonnet
>            Priority: Blocker
>             Fix For: 19.0.0.Beta1
>
>         Attachments: memory-leak-bad.png, memory-leak-good.png, wildfly-thread-leak.png
>
>
> There seems to be a memory leak when a deployment is redeployed multiple times (100 times in our test). This is very similar to what has been described in WFLY-10991. Also first commit this started to happen is [this one|https://github.com/wildfly/wildfly/commit/74170b5f49dd83f6b9ebd489f85e130df5521549] - JaegerTracing and Apache Thrift dependencies update. Thus I selected MP OpenTracing component for this issue.
> Test and deployment is same as is described in WFLY-10991.
> Size of the extra heap in use is about 27MB plus when compared to the initial size before multiple redeploy operations.
> I've tried to check manually via [visualVM|https://visualvm.github.io/] tool. Screenshot with suspicious jaegertracing instances are attached - there are much more jaegertracing class instances with new version of Jager Tracing and Apache Thrift dependencies, which is suspicious.
> Interesting thing is that when microprofile-opentracing-smallrye subsystem is removed via:
> {code}
> /subsystem=microprofile-opentracing-smallrye:remove()
> {code}
> the memory leak is still present. This is kind of confusing to me.



--
This message was sent by Atlassian Jira
(v7.13.8#713008)