Jaeger Tracer returns null activeSpan for traced request

[gmpatter]

Environment Details

• Helidon Version: 2.3.2
• Helidon MP
• JDK version: 11.0.9
• OS: MacOS 11.4

---

Problem Description

With Helidon MP 2.3.2 I’m seeing an issue with Tracing. If I add @Traced annotation to an endpoint method and then try to access the active span using the injected Tracer instance, there is no active span, so getting a NPE trying to log to the span within the endpoint method

Steps to reproduce

Create a new helidon-quickstart-mp application.

Add the tracing and jaeger dependencies:

<dependency>
  <groupId>org.eclipse.microprofile.opentracing</groupId>
  <artifactId>microprofile-opentracing-api</artifactId>
</dependency>
<dependency>
  <groupId>io.helidon.microprofile.tracing</groupId>
  <artifactId>helidon-microprofile-tracing</artifactId>
  <scope>runtime</scope>
</dependency>
<dependency>
  <groupId>io.helidon.tracing</groupId>
  <artifactId>helidon-tracing-jaeger</artifactId>
  <scope>runtime</scope>
</dependency>

Update the GET endpoint to be traced and use the opentracing api to log to the active span:

@Inject
Tracer tracer;

@Path("/{name}")
@GET
@Produces(MediaType.APPLICATION_JSON)
@Traced
public JsonObject getMessage(@PathParam("name") String name) {
  tracer.activeSpan().log("Some endpoint span logging.");
  return createResponse(name);
}

[spericas]

@gmpatter You seem to suggest this was the result of upgrading to 2.3.2. Which version did you upgrade from?

[gmpatter]

@spericas our apps are currently on 2.3.0. But when I reproduced this with the helidon-quickstart-mp app, I couldn't reproduce with 2.3.1 but could reproduce with 2.3.2. Sorry, would have been helpful if I'd added that! Also tried switching from jaeger dependency to zipkin but didn't see the issue. So seemed to be specific to the jaeger dependency.

[spericas]

This is related to the PR #3134. This improvement assumed switching-and-forgetting a thread and resuming processing in another. However, if any other context switch happens between the time the tracing pre-matching filter runs and the resource method is invoked, the original span set by that pre-matching filter will be lost.

Such a context switch is triggered by the SecurityFilter in this example while running some async tasks. We need to distinguish between switching-and-forgetting vs. switching-and-returning. The original reason to clear the state was a memory leak.

[spericas]

PR #3207