[Bug] Vertx worker thread can't get TraceId

[naah69]

Search before asking

• I had searched in the issues and found no similar issues.

Apache SkyWalking Component

Java Agent (apache/skywalking-java)

What happened

In vertx 4.x agent,SWVertxTracer#toEntrySpan parse context in eventloop thread.
ContextManager can't be used in worker thread.

What you expected to happen

TraceId is N/A

How to reproduce

use vertx agent and invoke ContextManager#getTraceId in worker thread.

Anything else

No response

Are you willing to submit PR?

• Yes I am willing to submit a PR!

Code of Conduct

• I agree to follow this project's Code of Conduct

[naah69]

i had used filter to deal it.
but i think it is so ugly.
is there any better way to reslove it ?

[wu-sheng]

Let's see @BFergerson has any suggestions.

@naah69 For a community, there is nothing urgent. All PMC members are volunteers here, they just contribute and answer questions for their own interests.

[BFergerson]

I gave it a look. It might be an issue but it's a bit hard to tell without a reproducible example. It may not be an issue with worker threads but just how the Vertx plugin uses async spans. Calling ContextManager.getGlobalTraceId() in a RoutingContext handler returns N/A regardless if it's the event loop or worker thread. The tracing data is stored transparently in the request context.

Example:

[naah69]

yes，maybe we should find some invocation point to intercept to continue context snapshot in routing context.

[BFergerson]

I don't think I've considered how that would work before.

@wu-sheng, have you run into this situation before with the async spans? For example:

• an entry async span starts
• the user adds @Trace (or equivalent) to start a local span
• the entry async span stops

I haven't tested it but my gut feeling is the local span won't be assigned to the entry span as it would not be the active span.

---

I think the Vert.x plugin could add local trace spans before it gives back control to user code to fix this issue but I'm curious how other async span plugins handle it.

[wu-sheng]

From the agent core perspective, once the span is not finished, no matter in or async mode, the next span could be in the same trace context and treat the span as the parent.

[wu-sheng]

But if it has done stop(not async stop), it is gone.

[BFergerson]

Yeah, I verified that's the case. I don't think there is an issue here then.

@naah69, what exactly are you trying to achieve?