We have a WCF service hosted in IIS. I can see from log files that a client which sends a request that takes over 3 minutes to execute receives an HTTP 503 (Service unavailable) error.
How do I change the timeout? To test it worked I reduced the timeout to 3 seconds to make sure it actually timed out.
I've tried
<system.web>
<httpRuntime executionTimeout="3"/>
</system.web>
which seemed to do nothing.
I've also tried changing the binding to no avail.
<basicHttpBinding>
<binding name="basicHttp" receiveTimeout="00:00:03" sendTimeout="00:00:03" >
<security mode="TransportCredentialOnly">
<transport clientCredentialType="Ntlm" proxyCredentialType="None" realm="" />
<message clientCredentialType="UserName" algorithmSuite="Default" />
</security>
</binding>
</basicHttpBinding>
Note, I am trying to get the WCF service to return some sort of failure after a duration controlled by us. I'm not expecting the request that has taken longer than expected to terminate.
Any help most appreciated before I tear my hair out.
Just to clarify...
The service has been up and running for a few months. But when processing the occasional long running request, the client receives an HTTP 503 response after 3 minutes. In the background we can see that the request has been properly procesed but it has taken > 5 minutes. Obviously by this point it's too late as the client has already received an error response.
Other requests are being processed as normal.
The load on the system at this point is very low. In fact, this is a test environment and transactions are one at a time with no overlaps.
I'm also quite certain that the bindings are connected to the endpoints. I've opened the config file in the WCF Config Editor and everything is linked up correctly.
Is it even possible to configure a time out at this point in WCF? In way I would understand if not, but then why is an HTTP 503 error being returned?
All we would really like to do is control the length of time before the 503 response is returned.
Normally when I make a change in a binding that has no effect on the service endpoint, it is because the binding is not connected to the endpoint.
If everything is getting 503 now and it worked previously, it could be that the user account that is the identity of the application pool has an expired password.
If it is working for some calls and not for others, and the load has increased, then it could be that the clients are not closing the connections and you hitting the default limit for the maximum number of concurrent calls.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With