I recently encountered a confusing issue with WCF. An application that worked fine on RC1 suddenly started intermittently failing on the release build of .NET 3.0. What was most perplexing was that no errors were returned, no debug information was provided, nothing. Calls from the client to the server never returned but just hung and the server provided no fault information. It was as if messages just went into the aether.
After some consultation with the WCF team, it was determined that changes to the default serviceThrottling behavior between builds was the culprit. The defaults are 16 MaxConcurrentCalls and 10 MaxConcurrentSessions, which was changed between RC1 and the final release. So, the calls from the client truly were heading into the aether and the server wasn’t able to provide any information because it wasn’t able to even process them. Why was the server getting so hammered from just a single client? In this case, the client was spawning multiple threads (~10 proxies) and issuing multiple asynchronous requests (~15) from each proxy. You do the math and you can see what was happening.
The fix was to do two things. First, the <behaviors> section of the app.config file was updated as follows:
<serviceThrottling maxConcurrentCalls=”50″ maxConcurrentSessions=”50″ />
Note that I’m not an WCF expert and I’m not sure the sweet spot as far as performance vs. throughput when tweaking these numbers.
The other thing that was done to the application was to reel back the client a bit so that it wasn’t hammering the server with so many simultaneous requests. Fewer proxies were spawned and fewer requests were sent. There was no degradation in performance when doing this, as the client couldn’t handle all the responses it got anyway.
The moral of the story? If your WCF service starts misbehaving without any diagnostics, this may be the culprit.
Oh, and if you are still editing your WCF app.config file by hand, then you must immediately open SvcConfigEditor.exe from the SDK bin.