[
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)
