IIS restart causes many Connection_Abandoned_By_AppPool messages in log

iisiis-6

After about half a day the IIS 6.0 ASP (VBScript) web server appears to die. It accepts TCP connections (i.e. I can telnet localhost 80 successfully) however it does not return any response.

When I restart the server (going through My Computer -> Manage -> IIS -> All Tasks -> Restart) I get a lot of entries in C:\WINDOWS\system32\LogFiles\HTTPERR\httperr1.log at the time of restart that say:

... 80 HTTP/1.1 GET / - 843545307 Connection_Abandoned_By_AppPool DefaultAppPool
... 80 HTTP/1.0 GET / - 843545307 Connection_Abandoned_By_AppPool DefaultAppPool
... 80 HTTP/1.0 GET / - 843545307 Connection_Abandoned_By_AppPool DefaultAppPool

where the ... refers to the prefix of the line, e.g.

2010-03-17 10:05:06 127.0.0.1 4927 127.0.0.1 80

There are 583 such lines (Connection_Abandoned_By_AppPool) in my log at time of restart.

What could be the cause of this problem?

Best Answer

My guess is that something with the app fails, causing a whole bunch of requests to queue. When you restart IIS, it's not able to catch up in the 90 second timeout, so it has to forcible end all outstanding requests. So, what you see in httperr is the affect and not the cause.

When it fails, do static pages work? That will tell you if it's IIS or ASP that is at fault. Your telnet test is a great one. That's helpful.

Check the IIS logs just prior to the restart and see if there are any other clues as to which pages are server, or what are the last few requests that worked successfully. That may give some more clues.

Perfmon has some counters that can show the number of queue requests and errors. You may be able to watch that and trend when it fails and possibly tell when the root issue first triggers.

Related Solutions

Iis – Server 2003 IIS Error

This problem might occur because ASP.NET limits the number of worker threads and completion port threads that a call can use to execute requests.

Typically, a call to a Web service uses one worker thread to execute the code that sends the request and one completion port thread to receive the callback from the Web service. However, if the request is redirected or requires authentication, the call may use as many as two worker and two completion port threads. Therefore, you can exhaust the managed ThreadPool when multiple Web service calls occur at the same time.

For example, suppose that the ThreadPool is limited to 10 worker threads, and all 10 worker threads are currently executing code that is waiting for a callback to execute. The callback can never execute because any work items that are queued to the ThreadPool are blocked until a thread becomes available.

Another potential source of contention is the maxconnection parameter that the System.Net namespace uses to limit the number of connections. Generally, this limit works as expected. However, if many applications try to make many requests to a single IP address at the same time, threads may have to wait for an available connection. To resolve these problems, you can tune the following parameters in your Machine.config file to best fit your situation:
* maxWorkerThreads
* minWorkerThreads
* maxIoThreads
* minFreeThreads
* minLocalRequestFreeThreads
* maxconnection
* executionTimeout
To successfully resolve these problems, do the following...

The quote's continued here... If that doesn't work, you can dig deeper with what's explained here.

Tomcat – HTTP compression in IIS 6.0 causing problems with certain users

Ok, I think we've figured it out...

On the client side, Squid 2.5 and earlier doesn't understand "Transfer-encoding: chunked", so it delivers each chunk as the entire client request. Since it's only 1 chunk of the entire compressed request, it's invalid data and can't be read by the browser. (Not sure if this is an issue with other proxies)

On the server side, IIS always sends chunked encoding for Dynamic Compression (since IIS doesn't cache application responses, it has to compress each response on the fly, hence the chunked encoding).

The only way we can think of to fix this is to completely disable compression for HTTP 1.0 clients and only compress for HTTP 1.1 responses. The drawback is that anyone behind a proxy that sends 1.0 requests won't get compressed data and the site will load 0.5 - 1 second slower for those users.

Changes made in the metabase.xml file:

<IIsCompressionSchemes            Location ="/LM/W3SVC/Filters/Compression/Parameters"
...
HcDoOnDemandCompression="TRUE"
HcNoCompressionForHttp10="TRUE"
...
</IIsCompressionSchemes>

If anyone has a better solution, please let me know!

Best Answer

Related Solutions

Iis – Server 2003 IIS Error

Tomcat – HTTP compression in IIS 6.0 causing problems with certain users

Related Topic