Aborted WCF call in Silverlight

Tuesday, April 19, 2011
by asalvo

After making what I thought was a small change to a WCF service being consumed by a Silverlight Application, I was faced with an HTTP 504 error. My asynchronous call in Silverlight was started, and I know it was being received by the server because I had SQL profiler running and could see the data access call. Eventually the Silverlight application would throw an exception stating that a timeout exception had occurred.

Using the new built in network traffic monitor in IE9 developer tools showed that the HTTP result was “aborted” and I got the same information from FireBug in FireFox. It wasn’t until I fired up fiddler that I was able to see the 504 code and the actual response from the web server which was: “ReadResponse() failed: The server did not return a response for this request.”.

BlogPost2 BlogPost3 BlogPost4
IE 9 Developer Tools Network View Firebug (Firefox) Network View Fiddler Results

Searching Bing gave me some pretty varied results, with a lot of suggestions to increase the service timeout limit (which) I knew wasn’t the problem, and enough results to make me think it was an issue with the actual data being returned from the database. I decided to enabled service logs as to get detailed logging information on the server. This can be done by adding the following to your web.config file:

<system.diagnostics> 
  <sources>
    <source name="System.ServiceModel.MessageLogging" switchValue="Warning, ActivityTracing" >
      <listeners>
      <add name="ServiceModelTraceListener"/>
      </listeners>
    </source>
    <source name="System.ServiceModel" switchValue="Verbose,ActivityTracing">
      <listeners>
        <add name="ServiceModelTraceListener"/>
      </listeners>
    </source>
    <source name="System.Runtime.Serialization" switchValue="Verbose,ActivityTracing">
      <listeners>
        <add name="ServiceModelTraceListener"/>
      </listeners>
    </source> 
  </sources>
  <sharedListeners>  
    <add initializeData="App_tracelog.svclog" type="System.Diagnostics.XmlWriterTraceListener, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" name="ServiceModelTraceListener" traceOutputOptions="Timestamp"/>
  </sharedListeners>
</system.diagnostics>

With the service logs in hand, I fired up the Microsoft Service Trace Viewer and found my problem. I had forgotten to grant execute permissions on the new stored procedure I had just created. I guess I’ll be leaving the service tracing on while I continue to develop. Just make sure that you delete the log file every so often as it gets big very quickly. Also don’t forget to disable by default in your production environment.

BlogPost1

Comments

comments powered by Disqus