Issues with parenting using IIS thread-pools

[joshdmcc]

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.

[ThomsonTan]

@joshdmcc is the the function in a.cpp calls function in b.cpp then calls into function in c.cpp, and the latter 2 spans were parented correctly, and not with the first span which is the root span?

[joshdmcc]

No. When b.cpp's span is created, a.cpp's span is not assigned as the parent. We know that a's span shouldn't be assigned a parent because it is the root span, but we would expect it to be the parent of b's span. We've generally seen then that b's span is assigned the parent of c's span as expected.

[joshdmcc]

And for reference, we are using the the nuget package, version 1865.

[github-actions]

This issue was marked as stale due to lack of activity.