How: Web Service and handling Client Timeouts in the Web Service?

Question

I am trying to log what is happening when the Client gets a time out on a Web Service call.

Take a look at the HelloWorld code below. This is what I wish to do, but it seems IsClientConnected does not work as it allways return true.

[WebMethod]
public string HelloWorld() {
    //.. Do the Webservice stuff
    if (!Context.Response.IsClientConnected) {
        //Log some vital info about this call that timed out...
    }
    return "The WebService Result";
}

Does anyone know another way to check the state of the Web Service call?

When clients disconnect from a webservice call, there are no Exceptions thrown in the Web Service. The code continues to run untill it is done and then returns its result into nothingness (as the connection is closed).

Answer 1

I would expect each Web Service call to be a request/response. In the event of an error such as the service being unavailable or timeouts I would expect an exception to be thrown.

So is it possible to surround the call with a try catch?

Answer 2

It is better to subscribe to some sort of an event than to check some flag. Basically, ASP.NET is killing the request because it is taking longer than the configured timeout value (executionTimeout setting in httpRuntime element). However, I am not so sure if there is such an event from ASP.NET runtime. Apparently, it does not raise any exceptions either. So there appears to be a disconnect between your service and ASP.NET runtime in this particular case. I would be interested in knowing if there is a way/trick to accomplish what you're after.

In the meantime, you may look into ASP.NET performance counters. There is one called 'Requests Timed Out'. It may include requests that timed out while waiting in a queue or during execution. You can read that performance counter for your web service at the beginning and at the end of your web method. If the number jumped, that means a request just timeout. It may not necessary mean that the jump corresponds to that particular request but in any case you can still log some information such as parameters passed to the web method, elapsed time, etc that might be helpful. You can also increase executionTimeout value in web.config to allow for more time while you're trying to optimize your web method to run quicker if you have clients needing an immediate solution.

If this an asmx web service, you may want to look into Session_End event in global.asax. It may get called when ASP.NET kills the request.

Just some thoughts.

Answer 3

This will depend upon the details of the Web Service framework you are using. From what you show I would be unsurprised if you there is no mechanism to detect this.

Consider that in general a Web Service need not be even using a transport such as HTTP, you could be responding via queues, or even email. In general you cannot as the server implementation of a simple Web Service be sure that your client has seen the answer. What would you infer if your test did work? At the instant you made the test he's there, a nano-second after you decided not to log, but before you've returned he's gone. There is no transactional relationship between Client and Server in simple SOAP/HTTP.

There are addional Web Service standards to address some of these issues, but usually you neeed to design your Web Services on the assumption that the caller may not see the answer. (perhaps you also provide status services, so a client can drop off and then come back and ask "did you process order "345").

Please tell us what you want to achieve with this logging, maybe somebody has a design approach to help.

Answer 4

HTTP protocol has no specification how server can ping client. The sense of IsClientConnected - to check if exist some 'unsatisfied' query for render HttpResponse. And may be (I'm not sure) if client supports keep-connection-alive.

Think about pulling architecture - were you have one-way method, and some watch-dog from client side to check periodically if method done.

Answer 5

I think that in order to get IsClientConnected to return false, the part of your web service code that says "//.. Do the Webservice stuff" would have to take longer to execute than the client's timeout setting. You could probably simulate this by setting the client's timeout to 60 seconds and putting a Thread.Sleep(70000) in your web service code before the IsClientConnected call.

However, I don't think even this would result in IsClientConnected's returning false. Timing out on a web service request and resetting the connection to the server are two different beasts. If Response had a method called IsClientStillWaitingForThisWebServiceCallToReturn, that might do what you want.

I think you could get IsClientConnected to return false if you physically disconnected the client from the network while the web service method was still in the part before the IsClientConnected check, but I'm guessing this isn't what you want.

Answer 6

I don't believe there will be an exception in general. Even if the service were sending back a long response, such that the outgoing transmission window closed, and timed out waiting to be able to send bytes, all of this would be occurring after the web method had returned back to ASP.NET.

What you should do is learn which web methods are taking too long. You can begin to do this by turning on tracing, as shown in "Enabling Tracing in ASP.NET Web Services". You may then need to go further, and profile the service to see where time is being spent.

You should also look carefully at the event logs. In particular, look for warning events from the "ASP.NET" event source. These come from ASP.NET Health Monitoring. I recommend you get to know the Health Monitoring system, as you may find it does many things for you that you'd have to write yourself, simply at the cost of configuration.