Did you know it is now easier to debug the server side PollingDuplex in Silverlight 4? With the addition of tracing, you can now get a peek at what is happening internally within your service. Traces from PollingDuplex will include information about what failed in communicating with your clients and how it was handled.
Enabling tracing is as simple as adding this configuration section in your Web.config file.
<source name=“System.ServiceModel.PollingDuplex“ switchValue=“Information“>
<add type=“System.Diagnostics.DefaultTraceListener“ name=“Default“/>
<add initializeData=“.\MyPollingDuplexServiceTraces.svclog“ type=“System.Diagnostics.XmlWriterTraceListener“ name=“xml“/>
Once configured, restart your service. If you use IIS, updating the Web.config will automatically recycle your service. Voila! Tracing is enabled.
Using this configuration, your traces are stored in XML format in a file called MyPollingDuplexServiceTraces.svclog. You can review the content of this file using Service Trace Viewer (SvcTraceViewer.exe). This tool is part of the .NET Framework SDK and is part of a standard Visual Studio install. Below is a sample screen capture of a trace file I generated from a service that seemed to deny clients to connect.
From this, I see that the server is overwhelmed by the number of incoming new client connections. From there, I can try to find a cause. Maybe the server hardware is too slow? Or is the MaxPendingSessions throttle modified to a value that is too low? I also see there is a MaxSessionsPerAddress throttle that is hit. Maybe there is a client that is attempting to open and maintain a large number of connections? In this case, my service is using a Polling Duplex binding set with very low MaxPendingSessions.
Our team hopes you will find this addition useful. Your feedback is always welcome, so please peruse the commenting section. Happy tracing!
Developer, Silverlight WCF team