[
https://issues.apache.org/jira/browse/CAMEL-21472?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17902932#comment-17902932
]
Pasquale Congiusti commented on CAMEL-21472:
--------------------------------------------
I have identified the main reason of the failure which is the fact we're
closing the scope too fast. I still need to verify the mechanism to restart the
trace once the exchange is complete. This is the traces I am getting:
{code}
10:13:21.909 [9e8c45a66385b66a603a75b4cf089c8d, f4e0aee994b9d56c] in timer route
10:13:21.916 [9e8c45a66385b66a603a75b4cf089c8d, 411bbecf3add1bcc] in
aSlowerRoute
10:13:21.920 [9e8c45a66385b66a603a75b4cf089c8d, 411bbecf3add1bcc] still in
aSlowerRoute
10:13:21.921 [9e8c45a66385b66a603a75b4cf089c8d, a6e5da0571573e03] in
aFasterRoute
10:13:21.926 [9e8c45a66385b66a603a75b4cf089c8d, a6e5da0571573e03] still in
aFasterRoute
10:13:31.885 [9e8c45a66385b66a603a75b4cf089c8d, 950d66e2a86c8dd5] in timer route
10:13:31.886 [9e8c45a66385b66a603a75b4cf089c8d, 625c85843b506435] in
aSlowerRoute
10:13:31.888 [9e8c45a66385b66a603a75b4cf089c8d, 625c85843b506435] still in
aSlowerRoute
10:13:31.889 [9e8c45a66385b66a603a75b4cf089c8d, 263bfaf1847fac78] in
aFasterRoute
10:13:31.893 [9e8c45a66385b66a603a75b4cf089c8d, 263bfaf1847fac78] still in
aFasterRoute
10:13:41.886 [9e8c45a66385b66a603a75b4cf089c8d, 6f1cea732bd351c3] in timer route
10:13:41.886 [9e8c45a66385b66a603a75b4cf089c8d, a103fc4b3a433864] in
aSlowerRoute
10:13:41.888 [9e8c45a66385b66a603a75b4cf089c8d, a103fc4b3a433864] still in
aSlowerRoute
10:13:41.889 [9e8c45a66385b66a603a75b4cf089c8d, 7b525d393fa4af89] in
aFasterRoute
10:13:41.893 [9e8c45a66385b66a603a75b4cf089c8d, 7b525d393fa4af89] still in
aFasterRoute
{code}
However we really have a problem with the MDC context propagation that is not
working out of the box. The above traces are taken when using the MDC
instrumentation provided by Opentelemetry, which, IMO, should be the proper way
to handle. I'll continue working to see how to reset the trace properly and we
can have a further discussion once that is over.
> Opentelemetry is using the same traceId when exchange is fired from file or
> timer component
> -------------------------------------------------------------------------------------------
>
> Key: CAMEL-21472
> URL: https://issues.apache.org/jira/browse/CAMEL-21472
> Project: Camel
> Issue Type: Bug
> Components: camel-opentelemetry
> Affects Versions: 4.8.1
> Reporter: Thomas Gantenbein
> Assignee: Pasquale Congiusti
> Priority: Major
> Fix For: 4.8.3, 4.10.0
>
> Attachments: image-2024-11-26-09-59-35-555.png,
> image-2024-11-29-17-04-16-581.png, image-2024-11-29-17-06-26-116.png,
> image-2024-11-29-17-06-42-860.png, image-2024-11-29-17-12-49-768.png,
> image-2024-11-29-17-12-58-036.png
>
>
> *Problem*
> When using a consumer like {{timer}} or {{{}file{}}}, the traceId remains the
> same for all messages. When using a consumer like netty (or, I assume, any
> other http/tcp-based consumer), every call gets its own traceId as expected.
> See also
> https://camel.zulipchat.com/#narrow/channel/257298-camel/topic/Same.20OTEL.20trace.20for.20all.20messages.20into.20IBM.20MQ
> *Reproducer*
> [https://github.com/thomas-gantenbein-tga/camel-opentelemetry/tree/main]
> [~pcongiusti], thanks for your answer on Zulip Chat. Let me know if I should
> further explain or minimize that reproducer.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
