Our application is a reverse-proxy that uses IIS for its thread maintenance, and are using the ETW exporter. While onboarding OpenTelemetry, we noticed some strange behavior when trying to use the default span parenting flow.
Essentially, our application receives requests which we will be tracing end-to-end. Every request uses its own thread (and sometimes spawns child threads). At the beginning of each request, we obtain a tracer from our provider and set it as the tracer for that thread - every time we want to create a span, we obtain the tracer from our provider (also on the thread).
Currently, we create a span just after processing the request - this is the root span. Let's say this span is in a.cpp. We create that span and use WithActiveSpan to set it as active, which I believe places it on that thread's RuntimeContextStorage stack.
After creating span A, we call a function that goes to another file b.cpp. In this file, we create another span, span B. Based on the flow we've seen, when this span is created it calls GetCurrentSpan() which should obtain span A from the RuntimeContextStorage, and set it as the parent to B. However, this does not seem to be the case.
However, if we set span B as active, then in another file c.cpp where we go after a function call in b.cpp and start span C there, then we will see the parenting take place correctly.
When stepping through in the debugger, it almost looks like the times we encounter the thread local stack used in RuntimeContextStorage, it is in two different locations in memory. We have also checked that the tokens generated when setting the span A as active persist until it is destroyed, which is far after the rest of the spans would be destroyed.
We have also confirmed that everything in this flow described above is taking place in the same IIS thread the entire time.
We have had @lalitb helping us internally, but thought I would post for greater visibility.
Our application is a reverse-proxy that uses IIS for its thread maintenance, and are using the ETW exporter. While onboarding OpenTelemetry, we noticed some strange behavior when trying to use the default span parenting flow.
Essentially, our application receives requests which we will be tracing end-to-end. Every request uses its own thread (and sometimes spawns child threads). At the beginning of each request, we obtain a tracer from our provider and set it as the tracer for that thread - every time we want to create a span, we obtain the tracer from our provider (also on the thread).
Currently, we create a span just after processing the request - this is the root span. Let's say this span is in a.cpp. We create that span and use
WithActiveSpanto set it as active, which I believe places it on that thread's RuntimeContextStorage stack.After creating span A, we call a function that goes to another file b.cpp. In this file, we create another span, span B. Based on the flow we've seen, when this span is created it calls GetCurrentSpan() which should obtain span A from the RuntimeContextStorage, and set it as the parent to B. However, this does not seem to be the case.
However, if we set span B as active, then in another file c.cpp where we go after a function call in b.cpp and start span C there, then we will see the parenting take place correctly.
When stepping through in the debugger, it almost looks like the times we encounter the thread local stack used in RuntimeContextStorage, it is in two different locations in memory. We have also checked that the tokens generated when setting the span A as active persist until it is destroyed, which is far after the rest of the spans would be destroyed.
We have also confirmed that everything in this flow described above is taking place in the same IIS thread the entire time.
We have had @lalitb helping us internally, but thought I would post for greater visibility.