You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@skywalking.apache.org by GitBox <gi...@apache.org> on 2019/03/14 01:50:40 UTC

[GitHub] [incubator-skywalking] wu-sheng edited a comment on issue #2341: Support plugin for Vert.x

wu-sheng edited a comment on issue #2341: Support plugin for Vert.x
URL: https://github.com/apache/incubator-skywalking/issues/2341#issuecomment-472672633
 
 
   > Why would I need to know what the parent span is? Each span is dealt with individually. If I open a span I have to make sure to close it. If that happens then by the time the response is ready the active span will be the correct span to close.
   
   First of all, there isn't about you need to know the parent span. It is more about when tracing context could **finish** automatically and in the right time. In SkyWalking design and its API, you could notice that we don't have an API called `TracingContext#finished` from any plugin, just inside TracingContext triggered automatically, **WHY?**, because no plugin knows he is the last/first span. 
   
   In codes level, read `TracingContext#activeSpanStack` and `EntrySpan`(also its parent `StackBasedTracingSpan`), you will find out the span finish operation need to do in the exact same order as open it. Also `TracingContext` is in the `ThreadLocal`, which ones, one thread could only have one TracingContext.
   
   Based on this background, how do you `don't finish the entry span` but switch the `TracingContext` to another request? 
   
   So, things like `EntrySpan is retrieved` only could happen when tracing context doesn't finish even all spans finished(removed from the active stack). That is key I mean for new `TracingContext` implementation, hold the context and span, make you have the chance to change/adjust the span.
   
   Does this make more sense to you now? 
   
   This is a very complex scenario. Argue and the trade-off between development convenient and API capabilities. Most tracing systems ignore this to do based on Dapper paper says, so backend will face heavy payload. But they, like Zipkin and Jaeger, are not APM solution, so this doesn't matter for them. In another way, this design is common in APM vendor core, which they keep in the shadow :)

----------------------------------------------------------------
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:
users@infra.apache.org


With regards,
Apache Git Services