ASP.NET IIS 5.0 - Server side timeout after 300 seconds?

[Christian Buchner]

Hi there.

I deployed a .NET webservice, written in C# and managed C++
on a Windows 2000 Professional box, with IIS 5.0 installed.

The service provides an API for encoding media files which
can take a long time (several minutes). My synchronous API
calls hence will only return after several minutes.

The problem is: I am getting a timeout from the server. The
exact message returned after about 300 seconds is given below.
I already set the maximum connection time to 86,000 seconds (a day).
Both for the webserver (globally) as well as for the application
(the webservice). Both available from the IIS MMC administration
snap-in.

Is there any other timeout definition that I missed? Maybe
somewhere in the .NET framework (web.config file)?

HTTP/1.1 500 Internal Server Error
Connection: close
Date: Thu, 01 May 2003 04:38:53 GMT
Server: Microsoft-IIS/5.0
Content-Type: text/html
Client-Date: Thu, 01 May 2003 06:29:02 GMT
Client-Response-Num: 1
Title: Server Unavailable

The web application you are attempting to access on this web server is currently unavailable.  Please hit the "Refresh"
button in your web browser to retry your request.

Administrator Note:
An error message detailing the cause of this specific request failure can be found in the system event log of the web server.
Please review this log entry to discover what caused this error to occur.

[Christian Buchner]

> An error message detailing the cause of this specific request failure can be found in the system event log of the web server.

Ah. I looked into the event log and found something about
the aspnet_wp.exe (worker process) being recycled because
it did not answer any requests for 180 seconds.

How would I disable this recycling process - or at least
lengthen the timeout value? I did not find the settings
in the IIS 5.0 configuration

Only IIS 6.0 on Windows 2003 server has all those nifty
application pool tweak settings.

[Dave Morgereth]

You need to edit the Machine.Config file on the web server. Its in the
WinNT\Microsoft.NET\Framework\<version>\Config folder (where <Version> is
the .NET framework version). You need to increase the
responseRestartDeadlockInterval setting, which is in the <processModel>
element and has a default value of 3 minutes, which is why you get the error
after 180 seconds. For example:

<processModel enable="true" timeout="Infinite" idleTimeout="Infinite"
shutdownTimeout="0:00:05" requestLimit="Infinite" requestQueueLimit="5000"
restartQueueLimit="10" memoryLimit="60" webGarden="false"
cpuMask="0xffffffff" userName="SYSTEM" password="AutoGenerate"
logLevel="Errors" clientConnectedCheck="0:00:05"
comAuthenticationLevel="Connect" comImpersonationLevel="Impersonate"

responseRestartDeadlockInterval="00:03:00" <!-- increase this
setting -->

responseDeadlockInterval="00:10:00" maxWorkerThreads="25" maxIoThreads="25"
/>

By the way, your architecture may have scalability issues. If you only have
a "few" concurrent users (< 20) I think your current architecture will work
fine. However if you're anticipating hundreds of users, you may want to use
some sort of queuing mechanism (eg. MSMQ). Basically the ASP.NET/IIS
architecture "prefers" relatively short-lived transactions. By creating a
long-running transaction you're really "fighting against" this philosophy.
Each web service invocation ties up an ASPNET_WP process for the duration of
the request, which is why IIS kills the ASPNET_WP process when the
responseDeadlockInterval timer expires. IIS assumes your web service is in
some sort of deadlock and kills the thread. Increasing the
responseDeadlockInterval allows your web service to run to completion,
however it means that each concurrent request could require a separate
ASPNET_WP process. If your workload generates a lot of long-running web
service requests, you could overwhelm the web server. Again, it may not be
an issue if your workload is small, but its something to think about.

Regards
Dave