Thoughts on Application Pool Recycling and Application Availability

Question:

I am running IIS 6.0. We are currently trying to incorporate our application pools to recycle every 2 hours. The problem is everytime the the pool is recycled and the process is killed everyone connected to that webpage loses all connectivity and they have to log back into their applications that they were running. I have read about overlapping but i do not know where to go and check to see if it is still set to the default (overlapping) or if it is set to non-overlapping.

Does anyone have any suggestions on how to keep our recycle process going without our clients getting kicked out of their applications

thank you for any help

Answer:

When you recycle an application pool, HTTP.SYS holds onto the client connection in kernel mode while the user mode worker process recycles. After the process recycle, HTTP.SYS transparently routes the new requests to the new worker process. Thus, the client never "loses all connectivity" to the server - the TCP connection is never lost - and never notices the process recycle. Also, your issue is not related to overlapped recycling (enabled by default) because that does not involve connectivity nor state.

I believe your problem is with the applications running in your application pool that store state within the process, such as whether a user is logged in or not. Everytime the process recycles, that state is automatically lost... which is by-design since that is what a process recycle accomplishes. As a result, your users "lose all connectivity" and "have to log back into their applications" to re-establish that lost state. The only way to fix this is for your applications to store its state outside of the IIS6 worker process such that it is friendly to being recycled.

The following blog entry talks more about what is going on:

Now, lots of people have wondered why IIS does not provide facilities to somehow "save" the in-process session state prior to recycling and then "restore" it after the recycle, so that all applications run by IIS are automatically friendly to being recycled. The astute reader should realize that this request has several problems, most prominently:

  1. One reason to recycle a process is to proactively get rid of potentially bad/stale state that leads to crashes, hangs, or memory leaks. If IIS simply saves and restores all state across the process recycle, both good and bad, then it defeats the purpose of the recycle.

  2. Assuming that IIS has some magical way to determine the bad state from the good state and only toss away the bad state, what happens to the user application that depend on both the good and what WAS the bad state? How can IIS determine a "good" value for that bad state to prevent introducing logical errors into the user application?

    One can argue that IF IIS can determine the good value, then the application should never get the bad value to begin with... and recycling is not necessary so this discussion is moot. ;-)

Thus, in order for you to keep your process recycling AND not have your clients getting kicked out of their applications, you must make sure they are architected to work with recycling by storing its state outside of the IIS worker process. Depending on the application, this may not be possible, but this is really a problem for you to solve...

Personally, I think it is strange that you are trying to establish a process that recycles the application pool every 2 hours. This sort of aggressive action usually indicates the presence of some misbehaving user code, and you usually get better bang-for-the-buck by fixing that bug (see this blog entry for the diagnostic approach). The ability to health-monitor and application pool recycle is a crutch to help you hobble along in the face of adversity, to buy you time to fix the underlying issue... and not as a primary means of running a broken application which will ultimately cause your demise.

//David