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

Reply via email to