I intermittently get the following exception in my .Net WCF Service. \"The HTTP service located at http://MyServer/TestWCF/MyService.svc is too busy.\"
Am I missing
The only source of this exception that I am aware of is if you are using sessions, and you manage to hit the MaxPendingChannels throttle,. Its default is something pretty low like 4. You could try setting it higher (128 for example), or if you just want to repro, set it to 1 and you should see it under load testing.
See here for more information about sessions: http://msdn.microsoft.com/en-us/library/ms733795.aspx
It is not just the maxConcurrentSessions, it is also how long the session lasts.
If the client does not close the connection, it will remain open until it timesout. You could then hit the maxConcurrentSessions limit with very little activity on the server.
My Solution would be, Check the App.Config file, whether the service tag is there for this particular service.
eg:
<service name="MyServices.ServiceName">
<endpoint address="" binding="wsHttpBinding" bindingConfiguration="TestBinding" contract="MyServices.ServiceName">
<identity>
<dns value="localhost" />
</identity>
</endpoint>
<endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" />
<host>
<baseAddresses>
<add baseAddress="http://localhost:8732/Design_Time_Addresses/MyServices/ServiceName/" />
</baseAddresses>
</host>
</service>
If you're service is running under your account (Identity), it's quite possible that you've recently changed your password--you'll need to reset it for its IIS application pool in Advanced Settings | Identity dialog box.
You could definitely try to increase the maxConcurrentSessions
and maxConcurrentCalls
in your service throttling behavior to the standard values of 30 or so and see if that makes the error go away. Server too busy would seem to indicate that more requests have come in than area allowed by your service throttling behavior, and they've been discarded since no service instance became available to service them within the given timeout period.
My answer would be, check if the app pool is up and well?
I've seen this error occurring when the app pool has died due to exceptions being thrown that aren't caught.
Consider for example, custom config sections - having an error in there, will cause your app to fail before it's even started. Too many of these in a short space of time will kill the app pool.