thomas-gantenbein-tga commented on PR #16386: URL: https://github.com/apache/camel/pull/16386#issuecomment-2507302083
I believe I understand why thread #3 -- the one that finishes the job after my "delay" -- doesn't get a traceId at all first and then traceIds get mixed up: Information about the current span, the span context and the context itself is stored in ThreadLocalStorage. `OpenTelemetryTracer#startExchangeBeginSpan` doesn't get the chance to be executed _for thread #3_ when the route reaches the delay EIP, so there's no information about a current span in ThreadLocalStorage at first. Later on, when thread #3 continues to execute the second direct route, `OpenTelemetryTracer#startExchangeBeginSpan` gets executed, which gets the parent span with the correct traceId. This also explains why my "fix" makes the traceId appear already the first time on thread #3: I store the current span on the _root_ context. So there is still no information about the current span the first time tread #3 does something in ThreadLocalStorage, but there is information in the root Context -- which may be stored statically somewhere, but I don't know for sure. And this, in turn, also explains why my "fix" still doesn't make everything work: It makes it work only the first time for a thread -- under certain conditions. If I am right, you'd have to find a way to pass the current spanContext and Context not only across routes (via an exchangeProperty and by invoking `OpenTelemetryTracer#startExchangeBeginSpan` on exchangeBegin, but also across EIPs _within_ a route. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: commits-unsubscr...@camel.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org