Over a million developers have joined DZone.

Propagating the ActivityId to a WCF service


In case you don't already know, the ActivityId is something we use to correlate trace events when logging so we know which 'start' goes with which 'stop' on a busy server. I wrote about it in this post.

Immediately after that post I blogged about a custom WCF message inspector that smuggled the ActivityId in a header. It turns out this was (almost*) superfluous as the WCF had recognised this as a common thing to want to do and added it as a feature.

However, it's pretty tricky to get this working as one of our readers discovered. On first impressions it's just a case of adding the System.ServiceModel trace source and set propagateActivity to true.

<source name="System.ServiceModel" propagateActivity="true"/>

"The propagateActivity attribute indicates whether the activity should be propagated to other endpoints that participate in the message exchange."

Easy right? No. This wouldn't do anything. Nada.Why? Not sure what the reason is but you must have a listener configured (even if you're doing nothing with it). I usually call it ignored to make it obvious.
<source name="System.ServiceModel" propagateActivity="true">
<add name="ignored" type="System.Diagnostics.DefaultTraceListener" />

Bingo! Now our ActivityId will propagate from the client to the server. Nice.

But remember... You must configure this at both the client AND the server for it to work!

Anything else? Oh yes...

The next thing that's likely to go wrong is that you might actually want to look at some of the output from the System.ServiceModel trace source so you turn up the volume and set the switchValue to 'All', for example, and add a real listener:

<source name="System.ServiceModel" switchValue="All" propagateActivity="true">
<add name="traceListener" type="System.Diagnostics.XmlWriterTraceListener" initializeData= "c:\log\Traces.svclog" />
All of a sudden the propagateActivity behaviour seems to break. Sure, you have an activityId at the server but it's different to the one you set at the client. Hmmm.

The documentation states why:

"If propagateActivity=true and ActivityTracing=off for a ServiceModel trace listener (regardless of whether tracing is enabled on ServiceModel), the following happen on either the client or server:
   - On operation request or sending response, the activity ID in TLS is propagated out of user code until a message is formed. An activity ID header is also inserted into the message before it is sent.
   - On receiving request or receiving response, the activity ID is retrieved from the message header as soon as the received message object is created. The activity ID in TLS is propagated as soon as the message disappears from scope until user code is reached."

So, if the switchValue is set to a value that includes ActivityTracing then the behaviour changes and you lose your ActivityId on server side. I hate this. It means if I want to use ActivityTracing (or All) in the System.ServiceModel trace source then we can't use propagateActivity in the way we'd expect.

( * which is why the message inspector I mentioned earlier is only almost superfluous and not totally.)

And remember, once again, ActivityTracing must be off at both the client and the server for propagateActivity to actually propagate your ActivityId.


Published at DZone with permission of Josh Twist. See the original article here.

Opinions expressed by DZone contributors are their own.

The best of DZone straight to your inbox.

Please provide a valid email address.

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}