Overview

When analyzing a heap dump for a potential memory leak, we noticed a huge amount of contextual instances of a Tracer hanging on the  creational context of the TracingCDIExtension from org.wildfly.microprofile.opentracing-smallrye.

We are using WildFly 24.0.0.Final.

Further tests showed that the instances are never cleared and thus eventually will consume all available heap.

Here is a Screenshot of the heap dump. Almost all of the 166779 elements are contextual instances containing the same JaegerTracer.

What we found out so far

During more detailed analysis we found that the leak occurs in the WildFlyClientTracingRegistrarProvider, and is kind of similar to the leak that was reported here https://issues.redhat.com/browse/WFLY-14094

The new instance is created whenever a ClientBuilder is configured with tracing via the ClientTracingRegistrar, and never deleted.

The reason for that seems to be that the instance is created via CDI.current().select(Tracer.class).get(), which creates a new dependent instance because the JaegerTracer does not have a scope. 
The bean to which the instance added in the CreationalContext is the TracingCDIExtension, since it is registered as Bean with the type Tracer on the AfterBeanDiscovery event. As CDI Extension, it is kind of ApplicationScoped, meaning that it will never be destroyed during the execution of the application. Therefore the instances will never vanish either.

Since the Tracer instance is not accessible in the ClientTracingFeature (where it's used later on) there is nothing we can do to fix this problem on our side. If you have any suggestions we are glad to hear them.