:: thoughts on team system and more RSS 2.0
# Saturday, 20 January 2007

This week I found myself wanting to look at the raw XML data sent between a client and a service. Of course the WCF tool SvcTraceViewer generally makes more sense to use for tracing, but sometimes it's necessary to look at the actual data on the wire. In such case a tcp trace tool can be used and placed in-between the caller and the service. In the end this was really easy to setup but in order to save someone else the hour or so to figure it out here's how it works:

For tracing I used Simon Fell's tcpTrace available at http://www.pocketsoap.com/tcptrace/.

First start tcpTrace. It needs to sit in the middle of the call so have it listen to the port the server exposes and forward to different port. Then configure the server to listen to the port tcpTrace forwards to using the listenUri configuration setting. The client doesn't have to be changed since all it does is call tcpTrace, which then forwards to the service. The config used looks like this: 

Server config:

<service name="Service.Calculator">
   <
endpoint address="http://localhost:8001/CalculatorService"
                 listenUri="http://localhost:8002/CalculateService"
                 binding="basicHttpBinding"
                 contract="Service.ICalculator"         
   />
</
service>

Client config:

<client>
   <
endpoint address="http://localhost:8001/CalculatorService"
                 
binding="basicHttpBinding"
                 
contract="ICalculator"

   />
</
client>

Saturday, 20 January 2007 13:51:49 (W. Europe Standard Time, UTC+01:00)  #    -
WCF (Indigo)
# Friday, 28 April 2006

I gave a talk on WCF Updates at the IBC Euroforum conference yesterday. There seemed to be a good interest in WCF, which of course was encouraging.

The presentation can be downloaded here: Windows Communication Foundation.ppt (567 KB)

Enjoy!

Friday, 28 April 2006 19:09:29 (W. Europe Standard Time, UTC+01:00)  #    -
WCF (Indigo)
# Sunday, 04 September 2005

After reading the Pallmann Indigo book I was a bit confused about how to use proxy objects, where the book stated the importance of calling .Close before disposing a proxy object. The standard principle for implementing the .Dispose pattern is to let the .Dispose method close all resources the object has open. If the class implements a behavior where it is possible to close and reopen it (like for instance a database connection) then .Dispose should do a graceful shutdown. Apparently in Indigo WCF this is not the case. Calling .Dispose without first closing the proxy will not perform a graceful shutdown (where buffers are flushed etc). It is therefore necessary to make the extra call to .Close before disposing the object.

The correct code to create, use and dispose a WCF object looks like this:

using (MyServiceProxy proxy = new MyServiceFrontProxy())
{
   result = proxy.DoStuff();
   proxy.Close();
}

Kenny Wolf has a good explanation of the details in the communication object life cycle.

It should be noted that this is the situation as of WinFX beta 1 and the behavior has been discussed to be revised for beta 2. Let's hope they decide that calling .Dispose is enough!

Sunday, 04 September 2005 20:27:51 (W. Europe Standard Time, UTC+01:00)  #    -
WCF (Indigo)
# Friday, 19 August 2005

Yesterday I did a presentation on WCF (Indigo) for the Swedish .NET User Group, SWENUG, in Gothenburg. As promised, here are the presentation and sample application I used:

PowerPoint presentation (1,56 MB)
OrderSample.zip (38,92 KB)

Friday, 19 August 2005 06:43:22 (W. Europe Standard Time, UTC+01:00)  #    -
WCF (Indigo)
# Tuesday, 09 August 2005

This is the first part in a series of small exercises where I try out the diagnostics features in WCF (Indigo). The articles will cover the Logging, Tracing, Performance Counters and WMI features in WCF.

 

First out is logging. Logging is controlled by using the configuration file for the application. By default all logging is turned off but it can be enabled individually for transport level-, service level- and malformed messages.

 

The following is an example that enables all message logging:

 

<diagnostics>

      <messageLogging

            filterTransportMessages="false"

            logEntireMessage="true"

            logMessagesAtTransportLevel="true"

            logMessagesAtServiceLevel="true"

            logMalformedMessages="true"

            maxMessagesToLog="100"

            maxNumberOfFilters="20"

            maxSizeOfMessageToLog="1000000"

      />

</diagnostics>

 

The highlighted attributes are the key attributes to enable the logging feature. logEntireMessage is set to true in order to have the whole message logged. The default is to only log the message header. The next three entries enable logging at the various levels. Depending on the binding used (and its configuration) there may be quite a few messages logged for each invoked operation. Since WCE logs all messages processed that may include messages things such as policy and security negotiation. It would be interesting to see complete flows of what is happening during the client-server interactions, but that is a different story...

 

The log files written are named like this:

 

   PID(AppDomainName)_Ticks_MsgIndex.xml

 

By default log files are written using a default trace listener, which will write the files at the following location:

 

   %windir%\system32\Logfiles\Messages

 

If another location should be used then a trace listener must be added in the "system.diagnostics" section in the configuration file for the source name “IndigoMessageLogTraceSource”.

 

The configuration below will write log files to a specified point using the provided MessageWriterTraceListener class:

 

<system.diagnostics>

   <sources>

      <source name="IndigoMessageLogTraceSource"

                   switchValue="Verbose">

         <listeners>

            <add name="multifile" type="System.ServiceModel.Diagnostics.MessageWriterTraceListener, System.ServiceModel, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"

                     initializeData="c:\logs\messages" 

                     maxDiskSpace="1000" />

         </listeners>

      </source>

   </sources>

</system.diagnostics>

 

The highlighted attribute sets the directory used for the message logging, in this case c:\logs\messages.

 

Unfortunately it seems like it is only possible to set the diagnostics configuration before the service is started. If the configuration is changed while the application is running it has no impact. This is of course a limitation that is going to be hard to deal with in a production environment. Hopefully there will be some more work done in this area before the v.1 release of WCF comes out the door.

Tuesday, 09 August 2005 22:12:11 (W. Europe Standard Time, UTC+01:00)  #    -
WCF (Indigo)
News
About the author/Disclaimer

Disclaimer
The opinions expressed herein are my own personal opinions and do not represent my employer's view in anyway.

© Copyright 2018
Mathias Olausson
Sign In
Statistics
Total Posts: 100
This Year: 0
This Month: 0
This Week: 0
Comments: 65
All Content © 2018, Mathias Olausson
DasBlog theme 'Business' created by Christoph De Baene (delarou)