WebRequest.Timeout bugs?

  • Thread starter Thread starter Jon Skeet [C# MVP]
  • Start date Start date
J

Jon Skeet [C# MVP]

I'm trying to understand why our mobile client isn't behaving
gracefully with a "hung" server. The server is accepting web requests,
but then not responding to them. Obviously we're working on that side
of the problem too, but we thought that by putting a timeout on the
WebRequest, and backing off in the same was as we do for other errors,
that we'd have a robust system. Apparently we don't.

I'm being absolutely rigorous in cleaning up - not only am I calling
Close() on every WebResponse received (including those embedded in
WebExceptions) but I'm also closing the ResponseStream - hopefully
unnecessarily.

The situation is slightly complicated by the server being hung in such
a way that the first request is rejected (correctly) with a 401
response due to the way our authentication works. (The first request
for any client is a 401 with a nonce to use for future authentication.)

The first request works fine with a suitably high timeout, although it
*does* time out if the timeout is set very low.

The second request (which the server actually hangs on) never seems to
time out.

It's as if the timeout only applies from the start of the call
(WebRequest.GetResponse) to the time at which the connection is
actually made.

Does anyone have any idea what's going on, and how to fix it?
 
I've found that if the server accepts the request, then sends back some
data, but never completes the response, the timeout MAY not trigger
properly. You may need to switch to asynchronous requests for tighter
control over the process.

-Dave
 
David D Webb said:
I've found that if the server accepts the request, then sends back some
data, but never completes the response, the timeout MAY not trigger
properly. You may need to switch to asynchronous requests for tighter
control over the process.
Click to expand...

Oh joy :(

Given that this only happens in very occasional situations (without the
connection itself going away, which I'll test but which I suspect is
enough to trigger the web request to complete with an error) I might
just detect it with my own timer which then triggers a message box
telling the user that the app will restart. Not pleasant, but of course
I'm hoping this will never happen in practice.

Next thing to look up is how to kill the process when there are hung
threads. Time to look on opennetcf.org...
 
Back
Top