jam01 commented on pull request #4044:
URL: https://github.com/apache/camel/pull/4044#issuecomment-663777815


   Ah I see. So in this case you want the kafka-connector to just fwd over the 
headers. Acting sort of as a non-trace-participant proxy. You don't care about 
capturing kafka specific tags like in 
[KafkaSpanDecorator](https://github.com/apache/camel/blob/master/components/camel-opentracing/src/main/java/org/apache/camel/opentracing/decorators/KafkaSpanDecorator.java).
 Your trace would be something like:
   ```
   [--------------------- trace --------------------------------------]
   [-- kafka outbound span --] possibly kafka outbound tags
                                          [--- camel:direct -------] server 
tag, camel-direct decorator tags
   ```
   instead of
   ```
   [--------------------- trace --------------------------------------]
   [-- kafka outbound span --] possibly kafka outbound tags
                               [--- camel-kafka inbound span---------] server 
tag, camel-kafka decorator tags
                                         [--- camel:direct --------] 
camel-direct decorator tags
   ```
   I hadn't thought of a scenario like this. I thought of it as an user error 
to receive an out-of-process request and not:
   * Extract the parent context
   * Create a new Span before as its child
   * Call ActiveSpanManager#activate before using a producer termplate.
   
   but that doesn't take into consideration libraries like kafka-connector 
:astonished: where you may not be ready to depend on a Tracing API yet. I also 
didn't know there were camel "components" that were not `Endpoint`s so I didn't 
consider that.
   
   So that said, I think I'll go ahead and allow internal endpoints to also 
extract from the headers. Perhaps it's worth noting in the docs that for 
application developers it _is_ an error not to do the process above when using 
producer templates.
   
   A little unrelated... Is the connector looking for `uber-trace-id` 
specifically? If so it wouldn't support tracers different than Jaeger when 
using default context propagation. I think the only way to do that "correctly" 
without relying on opentracing or opentelemetry is to use the standardized W3C 
header names (proxying like this is a driving force behind the standard), or 
make the headers to fwd configurable so library users could use any tracer 
implementation.


----------------------------------------------------------------
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.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


Reply via email to