]
Miroslav Novak commented on WFLY-12486:
---------------------------------------
Raising to blocker as MP Opentracing subsystem is enabled by default and even deployment
which is not using it is causing OOME when continuously redeployed.
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
Attachments: memory-leak-bad.png, memory-leak-good.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/74170b5f49dd83f6b9ebd489f85...] -
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.