Sergi Mola created CAMEL-22385:
----------------------------------
Summary: OpenTelemetry: Unclosed Span Scope with Parallel Multicast
Key: CAMEL-22385
URL: https://issues.apache.org/jira/browse/CAMEL-22385
Project: Camel
Issue Type: Bug
Components: camel-opentelemetry
Affects Versions: 4.14.0
Environment: Here's my configuration:
```
@Override
public void configure() {
// 1. Consume messages from a starting endpoint
from(RouteEndpoints.INBOUND_ENDPOINT.getValue())
.routeId("MyBusinessLogicRoute")
// 2. Validate the incoming message
.choice()
// A generic predicate checks for validity
.when(header("isValid").isEqualTo(false))
.log("Invalid message received. Routing to dead-letter queue.")
.to(RouteEndpoints.DLQ_ENDPOINT.getValue()) // Send to Dead Letter Queue
.otherwise()
// 3. Route the message based on its type
.choice()
// Check for a specific "type" field in the JSON body
.when().jsonpath("$[?(@.messageType == 'Confirmation')]")
.to(RouteEndpoints.STORE_ENDPOINT.getValue()) // Store confirmation
events
.otherwise()
// 4. Process other events in parallel
.multicast()
.parallelProcessing()
// Send to two different endpoints simultaneously
.to(RouteEndpoints.SEND_ENDPOINT.getValue(),
RouteEndpoints.STORE_ENDPOINT.getValue())
.end() // Closes the multicast
.end() // Closes the inner choice
.end(); // Closes the outer choice
```
Reporter: Sergi Mola
Attachments: with_parallel_processing.png,
without_parallel_processing.png
I'm encountering a tracing issue with the {{camel-opentelemetry2}} component,
specifically when using a {{multicast}} EIP with {{{}parallelProcessing{}}}.
*Problem:* The root {{Span}} for my SQS-triggered route is failing to close. I
believe this is because the {{Scope}} associated with this span is not being
properly closed and detached from the thread after the {{multicast}} with
{{parallelProcessing}} completes.
*Observed Behavior:*
#
## *Leaked Trace Context:* Due to the unclosed scope, subsequent, unrelated
spans (in this case SQS reads ) are incorrectly attached to the trace of the
completed route.
# *Cycle Repetition:* This behavior persists until a new message is consumed
from the SQS queue, which starts a new trace. However, this new trace then
suffers from the same issue.
*Key Finding:* The tracing behaves as expected (the root span's scope is closed
correctly) if {{parallelProcessing}} is removed from the {{{}multicast{}}}.
This suggests an issue with how the OpenTelemetry tracer handles the thread
context lifecycle during asynchronous, parallel processing. I've attached
screenshots illustrating the difference.
See attached screenshots.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
