Diagnosing "Request timed out" HttpExceptions

Asked 14/1, 2009 at 3:16 Answered 2/2, 2013 at 21:6

Here on StackOverflow, we're seeing a few "Request timed out" exceptions every day.

The facts:

Request timeout is the default 90 seconds
Occurs only on POSTs
Data posted is text, usually small (< 1KB), but can range to a few KB
No Form data is captured in server variables
Client UAs are diverse: IE5.5 - 7, Firefox 3.0.5, iPhone, Chrome
Client locations are diverse: UK, France, USA - NC, OH, NE, IN

We've tested a server-based timeout (i.e. using Thread.Sleep) and all form variables are correctly captured in the exception log - this leads us to believe the client is having issues sending the request in the allotted time.

Any thoughts on how to trap/debug this condition are very welcome!

Dollar answered 14/1, 2009 at 3:16 Comment(1)

This exact issue occurred for us when we switched from IIS6 to IIS7.5 Integrated mode. The results of our inquiry are available here: #4929615. – Stylo 1/9, 2011 at 20:45

I've got the same problem on our production servers that use a small AJAX webservice. After doing packet captures outside our firewall, we found that the POST to the service was coming in two TCP segments and the second segment never got to us. (first packet only contains headers, the second missing packet should be the json body) So basically IIS is just sitting there waiting for the rest of the POST. After the configured timeout, the server sends a RST packet to the client and logs the "Request timed out" error - which is correct behavior.

We are trying to get a client repro without much luck, but in our case this appears to be completely network related (or possibly some "security" software that doesn't like the contents of the post).

Schargel answered 2/4, 2009 at 14:5 Comment(5)

This is really all we've been able to determine - complete requests are not making it to the server. It's troubling, as you want to serve every request, especially POSTs for voting and asking/answering questions! – Dollar 23/8, 2009 at 8:31

It also looks like a lot of the unfinished requests are from "spammy" sources. – Dollar 16/10, 2009 at 1:18

Did you ever come up with a solution for this problem or are you just ignoring them? I am getting this a lot from legitimate requests (not spammy). – Amethyst 23/1, 2011 at 19:14

How is this an acceptable answer? It does say what the problem is.. but thats only half the problem. What is a possible solution? – Resor 7/5, 2012 at 19:14

Same here, I'm running into the same issue. Is there a solution to this issue? – Militarist 5/6, 2012 at 0:29

If you are running IIS 7 you could use the Failed Request Tracing. I haven't actually used it for timeouts, I mostly have set it up to capture just specific http error codes. But I know you can get it to dump traces of any request taking more than X amount of time.

Chicky answered 14/1, 2009 at 4:53 Comment(3)

Yes, we were going to turn this back on tonight - thank you for the reminder :) – Dollar 14/1, 2009 at 5:13

We're also going to add some trace statements to the affected urls' code paths - hopefully this will aid in finding the issue. – Dollar 14/1, 2009 at 6:10

See #442758 – Dollar 14/1, 2009 at 8:37

Have you tried posting manually via telnet and simply not completing the POST. I'd be interested to see if you could replicate the behavior you are seeing. Given the nature of the site, I wouldn't be surprised if you were getting a few malformed POSTs intentionally to try and hack the system.

I have noticed on occasion that I need to restart Safari in order to get SO working again after some action hangs, but I assumed it was my problem.

Resistive answered 14/1, 2009 at 3:16 Comment(1)

I wasn't able to reproduce the behavior - long running requests are just 504'ed. But this is good, because we know it's (probably) not client issues, as the ASP.NET pipeline isn't even reached. – Dollar 14/1, 2009 at 6:6

This article describes how to catch this using windbg:

http://blogs.msdn.com/b/asiatech/archive/2012/06/21/how-to-troubleshoot-httpexception-request-timed-out-asp-net-4-0-64-bit.aspx

Aerolite answered 2/2, 2013 at 21:6 Comment(1)

DebugDiag, not windbg. – Sevenfold 16/11, 2016 at 17:6

We used to see those a lot with our very high traffic web client -- wonder if it's related. What supposedly was happening was the HttpWebRequest (I'm assuming you're having problems with HttpWebResponse? Maybe they have the same issues) uses some janky thread pool underneath the covers, even when your requests are synchronous. Every now and then something would deadlock because some other .NET object higher in the stack was using the same system threadpool and one would starve the other out, eventually causing a timeout. I think the issue is better described here: http://www.deez.info/sengelha/2005/03/03/beware-threadpools-and-httpwebrequest/

Extravagate answered 14/1, 2009 at 4:53 Comment(1)

Very intense article there - it implies the issue was fixed in 2.0. Will research more on that to see if that's so. – Dollar 14/1, 2009 at 5:21

I would also scan the IP addresses in your logs to see if it's the same people having issues repeatedly. You know, it's just possible that some people are still using dial up accounts, or there may be other networking issues on their end. But, of course, don't just write it off without investigating as much as you can.

Mcclung answered 14/1, 2009 at 10:10 Comment(0)

We are experiencing the same "Request timed out" issue with our webservers after switching from IIS6 to IIS7. I believe the issue is IIS7-specific. My guess is that these errors were swallowed or ignored further up the processing chain in IIS6, before the request was handed-off to ASP.Net for processing. I am turning on Failed Request Tracing today to see if I can trap any more information about the issue. So far it seems that your explanation of client-side causes seems the most valid.

Trice answered 17/2, 2009 at 14:21 Comment(0)

Recommended topics

Hot tags