Dependencies not getting linked to the request

[ranjitkrishnan]

I am using ApplicationInsights WCF SDK for monitoring my service. I can see that dependencies of the requests are not getting linked to the original request.

The test service has following remote dependencies.

• Geocoding using Bing Map service Api
• Database from data is fetched
• Service logging into another database

When looking into the AppInsights. i can the request and dependencies. But the dependencies doesn't have link to the request. It looks like an independent telemetry.

See the screenshot attached.

Attaching the JSON calls captured using fiddler.

request.json.txt
SPdependency.json.txt

Here i cant find anything linking both the requests.

NB:
All the remote calls are asychronous calls using async awaits.
NET Framework: 4.5.2
Status monitor is installed on the server
Version : 0.26.0.16866

[tomasr]

I think what is going on is that the async requests are causing the dependency tracking calls to be made on threads where we can't get to the WCF OperationContext instance, so we can't fill in the telemetry event context with the necessary information. This can be seen on your sample telemetry event, as it doesn't have an operation id and similar data.

It's basically related to the issue described here.

@SergeyKanzhelev Do you know what is the bare minimum data we need to get dependency events correctly associated with the request? (It would be ideal to fill in everything, but I'm not entirely sure flowing the entire WcfOperationContext reference through the logical call context is desirable in every case...

[tomasr]

I've been checking with the WCF team on this, and it works on .NET 4.6.2 as is, as the flow of the OperationContext across async calls. I'm still working on an alternative meanwhile.

[ranjitkrishnan]

Just wanted to let you know the change you made works. I have downloaded the code and made the changes you suggested in WcfOperationContext. Now i can see dependencies getting linked to the request. One more question, do we really need StatusMonitor to be installed on the server if framework 4.6.2 is not present on the server

[tomasr]

@ranjitkrishnan Thanks for confirming that it works!

[ranjitkrishnan]

@tomasr When i was testing this piece more, i found one more issue. My service calls another service from within. These calls are not getting linked. It is linking SQL calls, HTTP Client calls which are all async awaits. But the WCF calls which is also async await, is not getting linked. Do you see any reason why it would not work ?

[tomasr]

@ranjitkrishnan Are you talking about a WCF call over an HTTP binding, or something else?

[ranjitkrishnan]

Yes. It is a WCF call over httpbinding. The remote service which my service is calling is hosted over SSL with certificate authentication

[tomasr]

Right now we don't have any explicit WCF client side support. I've thought about it, but the only way I can think of doing it automatically would be by injecting a client-side endpoint behavior, but that would still require adding manual configuration to the code.

However, I'd would've still expected to see the underlying HTTP calls themselves being tracked by the default dependency tracking.... Not sure if there are any known issues in that front. @SergeyKanzhelev, any ideas?

[ranjitkrishnan]

So is it a limitation of WCF application calling a remote WCF service or even an ASP.NET web api application calling a remote WCF service ?

[tomasr]

Can't say for sure without more tests. It could be something related to the async nature of the calls, because I've definitely seen regular HTTP tracking working for WCF calls, so doubt that's the issue itself.

[ranjitkrishnan]

Currently I have installed status monitor in the server. Is it really needed for dependency tracking?

[ranjitkrishnan]

@tomasr . I have installed 4.6.2 framework in the server. But still i cant see the dependent WCF calls (over http binding) linking to my service request as a dependency.

Can you think of any reason of why dependent WCF calls are not getting linked.

Attaching the trace captured from Visual studio. IN that one with mediasvcqa are the service calls which are not getting linked to service requests.

Telemetries.json.txt

Nuget version of WCF - 0.26.0.36170

[tomasr]

@ranjitkrishnan I see in some of the traces that the ai.operation.id property is missing, but not sure where those might be coming from. I suspect there are some calls being made in threads we can't find a relation to the original request thread.

Could you capture an ETW trace using PerfView with the following command line:

PerfView.exe /OnlyProviders=*Microsoft-ApplicationInsights-Wcf collect

And share it later? Maybe that will help us get to the bottom of it...

[ranjitkrishnan]

@tomasr Please find the perfview trace attached.
PerfViewData.etl.zip

[tomasr]

@ranjitkrishnan As I suspected, the trace shows there are a bunch of things happening in threads where no OperationContext can be found.

So sounds like you still have stuff going on in completely independent threads where the operation context is not getting flowed.

Without knowing more details about what your service implementation looks like, it's going to be hard to figure out what options we'd have to try to work around it.... can you tells us a bit more?

[ranjitkrishnan]

@tomasr , It is a normal WCF service where all the dependency calls are made asynchronously. The service has the following dependencies which are all async awaits.

1. REST based call to bing map service for geocoding
2. WCF service call which do some image processing
3. Database calls for fetching and saving data.

Here the WCF calls are the one which are not linked (or not having operation context). So lets give more details on that.

This service is hosted on Azure accessed over httpbinding. Since there can be multiple images to process, we create task for each image in a loop and call all these tasks in parallel using Task.WhenAll and await the Task.WhenAll. Service continue when all the images are processed.

Snippet looks like below:

        foreach (var url in media)
        {
            Task<MediaUrl> mediaProcessTask;
            mediaProcessTask = MediaSA.ProcessMediaResolutionForSaveAsync(url);

            imageSaveResponseTasks.Add(mediaProcessTask);
        }

        // Wait for the media processing to complete and then add the responses back to the collection
        await Task.WhenAll(imageSaveResponseTasks).ConfigureAwait(false);
        var result = imageSaveResponseTasks.Select(x => x.Result);
        return result;

[tomasr]

@ranjitkrishnan I've been trying to repro this, so far without success. Here's the code I'm using on the service:

public async Task<string> GetData(int value)
{
    AsyncServiceClient client = new AsyncServiceClient();
    List<Task> ops = new List<Task>();
    for ( int i = 0; i < 10; i++ )
    {
        ops.Add(client.DoWork());
    }
    await Task.WhenAll(ops).ConfigureAwait(false);
    return "Value was: " + value; 
}

Here's what the resulting telemetry looks like:

You can see that all 10 requests ended up being tracked correctly. I'll admit this is on .NET v4.6.2, so that might be related.

So I think there's gotta be something else going on here that is affecting the thread hand-off, but not sure what else could be going on....

[usma0118]

same issue experienced by us in .net 4.5