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"/>
<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">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.
<add name="traceListener" type="System.Diagnostics.XmlWriterTraceListener" initializeData= "c:\log\Traces.svclog" />
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."
( * 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.