You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@camel.apache.org by "Claus Ibsen (Jira)" <ji...@apache.org> on 2022/09/02 09:30:00 UTC

[jira] [Resolved] (CAMEL-11129) Capture fork/join pattern in OpenTracing

     [ https://issues.apache.org/jira/browse/CAMEL-11129?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Claus Ibsen resolved CAMEL-11129.
---------------------------------
    Resolution: Won't Fix

camel-opentelemtry is the recommended and prioritzed tracing component going forward

> Capture fork/join pattern in OpenTracing
> ----------------------------------------
>
>                 Key: CAMEL-11129
>                 URL: https://issues.apache.org/jira/browse/CAMEL-11129
>             Project: Camel
>          Issue Type: New Feature
>          Components: camel-opentracing
>            Reporter: Gary Brown
>            Priority: Major
>
> In the blog post http://www.hawkular.org/blog/2017/03/24/distributed-tracing-with-camel.html I instrumented the Loan Broker JMS example, which has a multicast/parallel and aggregation - but currently only the inbound/outbound endpoints create spans, so the opentracing data does not capture the fork/join structure.
> Therefore I wanted to explore ideas for how these control structures could be instrumented by the camel-opentracing component.
> As an initial spec, ideally what is required for the fork is a point where a 'fork' span could be created to act as the parent for a child span per concurrent path. This also means needing to be able to detect the start and end of the exchange for each path.
> Finally - when the join has been performed, need to gain access to the exchanges representing the concurrent paths, and associate the span context for each path with a new span representing the join point. Although haven't investigated in depth, potentially a proxy around the aggregation strategy might work - but not sure how this could be installed.
> This jira is just intended to investigate options, as currently the OpenTracing spec does not clearly define how this pattern would be represented, and would probably need additional reference types to be defined.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)