Finding ASP.Net Timeout Reason (During lengthy operations)

Question

I have an asp.net web application. It communicates to business layer through WCF. There is a lengthy database operation (taking two hours). This is a usual synchronous call. Initially I used to get exceptions related to WCF timeouts. For these exceptions, there used to be an exception thrown in the UI page (saying “Socket Timeout”). I resolved this using WCF binding settings in both service and client.

Now, after (exactly) one hour, I am getting error in browser window. Even though our application has a custom application error page, it is not showing customized error. Since there is no exception thrown in UI, I assume that it could due to ASP.Net timeout rather than WCF. I don't see any relevant log in event viewer also.

What are the ways/ tools that I can use to identify the exact reason for timeout?

Is it broswer setting/asp.net setting/iis setting issue?

IE Error Message: The page you are looking for is currently unavailable. The Web site might be experiencing technical difficulties, or you may need to adjust your browser settings. Note: At the bottom it says “Cannot find server or DNS Error”

Note: This functionality is used once in a month only. It is a functionality for administrator. So taking two hours is okay for us.

Note: I have the following WCF configuration. Service (receiveTimeout="05:30:00") and Client (receiveTimeout="05:30:00" and sendTimeout="05:30:00").

Note: It is unable to navigate to our custom error page and no exception is thrown.

Note: I am developing with Visual Studio 2005.

Note: The WCF is self hosted for testing.

Note: It is NetTCPBinding in WCF

Some Config Values used in the application are listed below:

<httpRuntime maxRequestLength="20000" executionTimeout="900"/>

  <forms loginUrl="Default.aspx" name=".ASPNETAUTH" protection="None" path="/" timeout="30" defaultUrl="Home.aspx">

  </forms>

</authentication>  

and-

<roleManager defaultProvider="MyRoleProvider" enabled="true" 
cacheRolesInCookie="true" cookieName=".ASPROLES" cookieTimeout="30" cookiePath="/"   cookieRequireSSL="false" cookieSlidingExpiration="true" cookieProtection="All">
  <providers>
    <clear/>
    <add name="MyRoleProvider" type="My.AccessControl.ServiceLayer.MyRoleProvider"  />
  </providers>
</roleManager>

Note: I am planning to disable '“Show friendly HTTP error messages” in IE. I am also planning to make customErrors mode=”Off” in system.web to test it further.

Answer 1

First , the browser is only going to wait for so long for a web server to respond and start producing a response. IE 7/8, I believe bail after 60 minutes. Dunno about IE 9. See KB181050 article for details. Firefox, Chrome, Safari, Opera are all likely to vary in how long they are willing to wait before deciding that there's no there there at the server.

Frankly, I think 60 minutes is awfully long to wait before deciding that the server isn't going to answer. 5 minutes ought to be more than sufficient. What would you assume if you asked for a web page and didn't receive any response from the server for more than a minute or two: wouldn't you ordinarily assume that the server is bolluxed up and cancel the request?

At any rate, when the browser abandons the request, it's going to close the socket and you'll get an error page from the browser. You won't see anything on the server end of things: it's still merrily grinding away. I assume, though, that IIS notices when the socket drops. Hopefully, at that point IIS will terminate the request.

Second , IIS itself is only going to wait for so long before deciding that something has gone south with the request processing. You should get an exception for this I believe.

Why on earth would you expect your users (and their web browser) to hang around for 2+ hours waiting on an HTTP request?

Set your admin app up so requests like these are queued up and processed asynchronously by some sort of daemon (or spawn a thread to do the asynchronous processing. Hand back some sort of ticket so the requesting page can poll periodically to see if the long-running request has been completed: at that point, hand back whatever constitutes the actual response for the request.

On the client browser, spawn such a request via an AJAX post. Let the client side javascript use the returned ticket to poll every 30 seconds or so until the request is complete. Voila! No more browser timeouts.

Answer 2

If you can host it on an IIS server, you can try using the FailedRequestTracing module.

http://learn.iis.net/page.aspx/266/troubleshooting-failed-requests-using-tracing-in-iis-7/

I've used it for troubleshooting timeouts previously.

Answer 3

会话可以超时还是（网络）应用程序在一小时点关闭？

Answer 4

您最好需要为WCF和ASP.net之间的通知以及AJAX实现双工服务，以便在客户端和Web服务器之间进行通知

Answer 5

The whole concept of waiting over HTTP for what you yourself described as a TWO HOUR operation is flawed from the git-go. As mentioned by other posters, you need to re-think your strategy. Kicking it off under some queued process and then providing users with some method to either poll for completion, or even sending them an email notification with a link in it is one way.

Go with the flow.