views:

285

answers:

1

We have a SOAP web service running on ASP.NET Web Services over IIS6 that exhibits a strange behavior when it processes a request that results in long server-time processing. Essentially if a request takes more than about 5 minutes to process on the server then IIS never sends the response back to the client, even though, from ASP.NET's perspective, the call completed. We know this because we write entries to an application log at the beginning and end of a web method call and those log entries do get written. However, no response is actually sent and the connection remains open, seemingly indefinitely. In one test, we saw the connection stay open for over 24 hours before we manually stopped the test client.

We have a test SOAP client that is able to detect the moment a response starts streaming down to it from the server and in the case where the server processing time takes too long, nothing is ever streamed down. Even with a large response payload, we should start seeing that response trickle down shortly after the web method's "end" application log entry is written, but we never see it.

The exact server processing time where things behave in this manor is hard to determine. We have one long-running test call that results in about 2.5 minutes of server processing time and that call results in a successful response to the client. We have another that takes about 8 minutes and that one fails as described above. So the threshold must be somewhere in between.

+1  A: 

I suggest that you call a web method to start the execution of your needed task, than use another method to poll the server for the task's completion. I had the same problem 2 years ago and i solved it this way. The client queues a task on the server then after some specified intervals asks the server for the result of the task.

I hope that helps.

O. Askari
That's not a bad idea. We're actually thinking of using this more "asynchronous" approach for other web methods that we will be adding in the future that we know will be long-running. The problem with this particular method is that most of the inputs result in relatively short-running calls; it's only a few edge cases that cause it to run long like this. It would be an added complexity to force our customers to use polling just for these cases.It would be nice to know what causes the server to simply not respond anymore. It almost seems like a bug in either IIS or ASP.NET Web Services.
twistedstream