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

[Miroslav Novak (Jira)]

    [ https://issues.redhat.com/browse/WFLY-12486?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13943668#comment-13943668 ] 

Miroslav Novak commented on WFLY-12486:
---------------------------------------

[~ehugonnet] thanks, I've tried WF build from https://github.com/wildfly/wildfly/pull/12878 and do not see any memory/thread leak. 

> 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)