lmolkova opened a new pull request, #8713: URL: https://github.com/apache/camel/pull/8713
Prototype for https://issues.apache.org/jira/browse/CAMEL-18661 **Looking for input on the overall approach** This change enables current span propagation to underlying libraries and end-user-code (for OpenTelemetry): for all spans created by Camel, it calls into `span.makeCurrent()` However, OpenTelemetry (and other tracing tools) rely on `ThreadLocal` to propagate context. They do it carefully for Executors, Reactor, etc, so it works in async scenarios. **Camel and other instrumentations have to close scope returned by `span.makeCurrent()` in the same thread where it was created to avoid leaking context (by leaving current span on current thread).** This is easy to guarantee with sync operations in Camel - ExchangeStarted/Sending and ExchangeCompleted/Sent events (where spans start and end) are called o the same thread. However, for async operations, they are called on different threads. This change also adds a new event - `ExchangeAsyncStarted` (naming needs more work), that notifies that `Processor.process` call has ended, i.e. operation has started. Tracers should end the scope (but not span) when this event is sent. **Alternative approach:** add a dependency on `camel-tracing` to `camel-base-engine` and call into `ActiveSpanManager` directly: ```java try(AutoCloseable scope = ActiveSpanManager.makeSpanCurrent(exchange)) { sync = processor.process(exchange, async); } ``` This would be easier to maintain and would more or less guarantee that scope is disposed on the same thread, however, dependency on tracing might not be desirable. -- 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
