Default AppPool Recycling Question

I have recently moved to IIS 6.0 from IIS5.0 for a web application in-use
24x7 that requires signing on with usernames/passwords that is stable
without problems (been running for 5 years without the need to periodically
restart it because of memory, bug problems, etc.). Without knowing default
settings, I was disturbed when seeing (in the Event Log) that my web
application was restarted at (seemingly) random times. I thought there was
an error in my program or COM+ components that it uses because of some new
unforeseen interaction with a new OS (2003 instead of 2000). I then found
out that the AppPool recycling default setting was enabled and set to
recycle every 1740 minutes (q 29 hours). I disabled the recycling.

My question is, when the AppPool recycles, doesn't that END all the Sessions
of current web users and essentially throws them off my secure web
application causing them to lose their current work (in data entry forms)
and then they have to sign on again?

If that is true, why would anyone make this a default for web applications,
when dozens of users are periodically thrown off the web application (and
they probably think something was wrong with their computer instead of
default web server behavior)?

Thanks for any explanation.

Re: Default AppPool Recycling Question

Don,

The new recycling feature of IIS6 is a mechanism for assuring high-
availability to Web Sites. Due to .NET (ASP.NET for that matter) tehre
has been a push for a RAD - Rapid Application Development - and while
the development cycle normally tends to follow closely deadlines while
bypassing the quality assurance tests, the need for a robust platform
was an obvious issue.

Recycling, technically speaking, is nothing more than the launch of a
new w3wp.exe (AppPool) to serve new http requests while the old
w3wp.exe being replaced will terminate after processing the already
started http requests. Everything InProc session will be destroyed
because all AppDomains (ASP.NET) and native WebApps (ASP) where the
session was created will be destroyed too.

As for the "session" question, with the arrival of ASP.NET, session
configuration has at least 3 options:
1 - InProc (same as ASP)
2 - StateServer (new to ASP.NET)
3 - SqlServer (new to ASP.NET)
4 - Custom ...

The (2) and (3) options are tipically used for load balanced sites,
since the request (depending on the balancing option) can hit any of
the servers on the farm. This way, the session content is not
dependent on the server where the session was created.

Finally, the "session" concept you speak about is definitely related
to the first (1) option. To overcome this you have tipically 2
options:
- convert your cookies to disk based cookies. Store a GUID in the
cookie, and store the "session" state anywhere (sql server for
example). This would be a custom made solution similar to option (3)
above
- convert all your code to ASP.NET and take advantage of all new
options available to you via the framework.

-- A final word of caution.
If you current environment locks the web server where the TCP session
has begun to the end user navigation, meaning there is no load
balacing and therefore no fault tolerance, then I would advise you to
reevaluate the solution.

Tiago Halm

Re: Default AppPool Recycling Question

Don,

Where I say
"- convert your cookies to disk based cookies."
there is no need. The cookies can still be session based (no disk
storage). The only requirement (as is in ASP.NET) is for the WebApp to
know where to lookup the GUID and the "session" property bag, which
can for example be in SQL Server or some other centralized storage
mechanism.

All the above remains valid.

Cheers,
Tiago Halm

Re: Default AppPool Recycling Question

First of all, thank you for the very detailed explanation and your time.

I use classic ASP 3.0 on one server and when a user signs on, I create a
Session Variable (e.g. "isValidUser") that I check for before EVERY page is
compiled and served. I do not use cookies (client-based or disk-based) or
SQL server to store Session state (although I see the many advantages of
such approaches for web farms). Also, the fact that EVERY page in this web
application is SSL encrypted (medical records) means that each Session has
to "stick" with one server anyway.

If I understand your answer "Everything InProc session will be destroyed
because ... native WebApps (ASP) where the session was created will be
destroyed too" this means exactly my worst fear will be realized with
recycling - ALL users currently using my application will be kicked off and
have to sign on again!

I may indeed move to ASP.NET but probably not for a year or two (it will
take that long to refactor a very complicated web application) but it sounds
like I have to disable recycling for my situation. Agree?

wrote in message
news:1189519564.157823.173980@d55g2000hsg.googlegroups.com.. .
> Don,
>
> The new recycling feature of IIS6 is a mechanism for assuring high-
> availability to Web Sites. Due to .NET (ASP.NET for that matter) tehre
> has been a push for a RAD - Rapid Application Development - and while
> the development cycle normally tends to follow closely deadlines while
> bypassing the quality assurance tests, the need for a robust platform
> was an obvious issue.
>
> Recycling, technically speaking, is nothing more than the launch of a
> new w3wp.exe (AppPool) to serve new http requests while the old
> w3wp.exe being replaced will terminate after processing the already
> started http requests. Everything InProc session will be destroyed
> because all AppDomains (ASP.NET) and native WebApps (ASP) where the
> session was created will be destroyed too.
>
> As for the "session" question, with the arrival of ASP.NET, session
> configuration has at least 3 options:
> 1 - InProc (same as ASP)
> 2 - StateServer (new to ASP.NET)
> 3 - SqlServer (new to ASP.NET)
> 4 - Custom ...
>
> The (2) and (3) options are tipically used for load balanced sites,
> since the request (depending on the balancing option) can hit any of
> the servers on the farm. This way, the session content is not
> dependent on the server where the session was created.
>
> Finally, the "session" concept you speak about is definitely related
> to the first (1) option. To overcome this you have tipically 2
> options:
> - convert your cookies to disk based cookies. Store a GUID in the
> cookie, and store the "session" state anywhere (sql server for
> example). This would be a custom made solution similar to option (3)
> above
> - convert all your code to ASP.NET and take advantage of all new
> options available to you via the framework.
>
> -- A final word of caution.
> If you current environment locks the web server where the TCP session
> has begun to the end user navigation, meaning there is no load
> balacing and therefore no fault tolerance, then I would advise you to
> reevaluate the solution.
>
> Tiago Halm
>

Re: Default AppPool Recycling Question

Don,

You do use session based cookies because ASP Sessions make use of
cookies. If not, how could IIS relate a given http request to its
Session property bag? :)

Given you have a 24/7 requirement, you still want to make sure IIS is
healthy, so monitor the resource usage (memory, CPU, etc...) closely.
If you see memory going up, then there is nothing left to do besides
recycling manually. Believe me that recycling in IIS6 will provide the
least damage and disruption compared to the old IIS5 stop/start.

Tiago Halm

Re: Default AppPool Recycling Question

Thanks. I never had to do the "old IIS5 stop/start" with my web application
that runs and runs ;)

wrote in message
news:1189522483.870348.119960@g4g2000hsf.googlegroups.com...
> Don,
>
> You do use session based cookies because ASP Sessions make use of
> cookies. If not, how could IIS relate a given http request to its
> Session property bag? :)
>
> Given you have a 24/7 requirement, you still want to make sure IIS is
> healthy, so monitor the resource usage (memory, CPU, etc...) closely.
> If you see memory going up, then there is nothing left to do besides
> recycling manually. Believe me that recycling in IIS6 will provide the
> least damage and disruption compared to the old IIS5 stop/start.
>
> Tiago Halm
>

Re: Default AppPool Recycling Question

The reason that IIS6 recycles every 29 hours by default (and we had a
reason for choosing 29 hours as the default value) is because more
likely than not, the web application running on it is unreliable and
literally needs to restart frequently.

Thus, IIS6 is built around the premise (admitedly cynical) that the
user's web application will not run for more than 24 contiguous hours,
features are planned accordingly, and defaults chosen. Worker
processes recycle every 29 hours, process startup and shutdown are
monitored, the process is constantly pinged to make sure it is
running, the process handle is tracked and signaled when it terminates
unexpectedly, etc etc.

Realizing that recycling is a normal part of operations, IIS6 also
makes sure to isolate such recycling from the end user -- the end
user's TCP connection never terminates during a recycle, due to some
kernel-mode magic. Combined with user-mode application which stores
session-state out-of-process (like ASP.Net Session State Service), one
is virtually guaranteed reliable uptime with no user-visible data
loss, even if the web application crashes after processing every
single user request.

This is about as good as IIS6 can make it -- given an unreliable web
application, make it appear reliable to the end-user, and do it
without requiring any fixes of the unreliable web application.

Of course, not all unreliable application can be made to appear
reliable -- if so, then we are all out of jobs! -- but IIS6 sure tries
a whole lot more to be resiliant.

In your case, it just happens that the resiliancy has a side effect on
non-persisted user state, but it can be easily adjusted.

Assuming your web application never has a problem and stays with in-
process session state, you will want to change these defaults:
1. Turn off the 29 hour periodic recycling
2. Turn off the 20 minute idle timeout

This will prevent unexpected loss of session state.

Of course, if you ever use an application with out-of-process session
state, you can leave everything as the defaults and never notice a
difference in functionality nor reliability.


//David
http://w3-4u.blogspot.com
http://blogs.msdn.com/David.Wang
//





On Sep 11, 8:45 pm, "Don Miller" wrote:
> Thanks. I never had to do the "old IIS5 stop/start" with my web application
> that runs and runs ;)
>
> wrote in message
>
> news:1189522483.870348.119960@g4g2000hsf.googlegroups.com...
>
>
>
> > Don,
>
> > You do use session based cookies because ASP Sessions make use of
> > cookies. If not, how could IIS relate a given http request to its
> > Session property bag? :)
>
> > Given you have a 24/7 requirement, you still want to make sure IIS is
> > healthy, so monitor the resource usage (memory, CPU, etc...) closely.
> > If you see memory going up, then there is nothing left to do besides
> > recycling manually. Believe me that recycling in IIS6 will provide the
> > least damage and disruption compared to the old IIS5 stop/start.
>
> > Tiago Halm- Hide quoted text -
>
> - Show quoted text -

Re: Default AppPool Recycling Question

Wow. Thanks for the detailed explanation and pointers.

I'm currently using good ol' ASP 3.0 with COM+ for my business logic, SQL
Server 2000 for the backend, and literally, my web application has run for
months at a time without a restart (and the only time I had to do a restart
was for Windows critical patches).

But are you saying that ASP.NET applications are inherently unstable and
that this recycling is really necessary for ASP.NET applications because
you've had to design IIS 6.0 to accommodate such instability/unreliability,
and need for frequent restarts?


"David Wang" wrote in message
news:1189586257.601722.76880@57g2000hsv.googlegroups.com...
> The reason that IIS6 recycles every 29 hours by default (and we had a
> reason for choosing 29 hours as the default value) is because more
> likely than not, the web application running on it is unreliable and
> literally needs to restart frequently.
>
> Thus, IIS6 is built around the premise (admitedly cynical) that the
> user's web application will not run for more than 24 contiguous hours,
> features are planned accordingly, and defaults chosen. Worker
> processes recycle every 29 hours, process startup and shutdown are
> monitored, the process is constantly pinged to make sure it is
> running, the process handle is tracked and signaled when it terminates
> unexpectedly, etc etc.
>
> Realizing that recycling is a normal part of operations, IIS6 also
> makes sure to isolate such recycling from the end user -- the end
> user's TCP connection never terminates during a recycle, due to some
> kernel-mode magic. Combined with user-mode application which stores
> session-state out-of-process (like ASP.Net Session State Service), one
> is virtually guaranteed reliable uptime with no user-visible data
> loss, even if the web application crashes after processing every
> single user request.
>
> This is about as good as IIS6 can make it -- given an unreliable web
> application, make it appear reliable to the end-user, and do it
> without requiring any fixes of the unreliable web application.
>
> Of course, not all unreliable application can be made to appear
> reliable -- if so, then we are all out of jobs! -- but IIS6 sure tries
> a whole lot more to be resiliant.
>
> In your case, it just happens that the resiliancy has a side effect on
> non-persisted user state, but it can be easily adjusted.
>
> Assuming your web application never has a problem and stays with in-
> process session state, you will want to change these defaults:
> 1. Turn off the 29 hour periodic recycling
> 2. Turn off the 20 minute idle timeout
>
> This will prevent unexpected loss of session state.
>
> Of course, if you ever use an application with out-of-process session
> state, you can leave everything as the defaults and never notice a
> difference in functionality nor reliability.
>
>
> //David
> http://w3-4u.blogspot.com
> http://blogs.msdn.com/David.Wang
> //
>
>
>
>
>
> On Sep 11, 8:45 pm, "Don Miller" wrote:
>> Thanks. I never had to do the "old IIS5 stop/start" with my web
>> application
>> that runs and runs ;)
>>
>> wrote in message
>>
>> news:1189522483.870348.119960@g4g2000hsf.googlegroups.com...
>>
>>
>>
>> > Don,
>>
>> > You do use session based cookies because ASP Sessions make use of
>> > cookies. If not, how could IIS relate a given http request to its
>> > Session property bag? :)
>>
>> > Given you have a 24/7 requirement, you still want to make sure IIS is
>> > healthy, so monitor the resource usage (memory, CPU, etc...) closely.
>> > If you see memory going up, then there is nothing left to do besides
>> > recycling manually. Believe me that recycling in IIS6 will provide the
>> > least damage and disruption compared to the old IIS5 stop/start.
>>
>> > Tiago Halm- Hide quoted text -
>>
>> - Show quoted text -
>
>

Re: Default AppPool Recycling Question

Actually, your web application sounds like the exception, not norm, of
web applications.

If users write web applications which perform half as well as yours,
IIS6 probably would not have its resiliancy/reliability features.

I am not saying that ASP or ASP.Net applications are inherently
unstable.

I am saying that historical data shows many application developers are
very capable of writing unstable applications regardless of the
framework, like ASP, ASP.Net, PHP, Perl, etc, yet they and their
bosses expect these applications to perform like stable
applications... and blame all failures on the web server. Thus, IIS6
attempts to defend itself by providing an illusion of reliability for
such unreliable applications (and the counterpart, DebugDiag, allows
one to pinpoint the party resposible for any unreliability, thus
pinpointing "who is to blame" and 90+% of the time, the issue is not
with IIS).

Now, this defensive posturing may have adverse effects on well-
behaving applications, but it is very easy to disarm those settings
from IIS6 for proven, stable web applications to minimize
interference. The contrary is obviously not true -- it may not be
possible to configure IIS6 to cover-up for unproven, unstable web
applications.


//David
http://w3-4u.blogspot.com
http://blogs.msdn.com/David.Wang
//





On Sep 14, 4:04 pm, "Don Miller" wrote:
> Wow. Thanks for the detailed explanation and pointers.
>
> I'm currently using good ol' ASP 3.0 with COM+ for my business logic, SQL
> Server 2000 for the backend, and literally, my web application has run for
> months at a time without a restart (and the only time I had to do a restart
> was for Windows critical patches).
>
> But are you saying that ASP.NET applications are inherently unstable and
> that this recycling is really necessary for ASP.NET applications because
> you've had to design IIS 6.0 to accommodate such instability/unreliability,
> and need for frequent restarts?
>
> "David Wang" wrote in message
>
> news:1189586257.601722.76880@57g2000hsv.googlegroups.com...
>
>
>
> > The reason that IIS6 recycles every 29 hours by default (and we had a
> > reason for choosing 29 hours as the default value) is because more
> > likely than not, the web application running on it is unreliable and
> > literally needs to restart frequently.
>
> > Thus, IIS6 is built around the premise (admitedly cynical) that the
> > user's web application will not run for more than 24 contiguous hours,
> > features are planned accordingly, and defaults chosen. Worker
> > processes recycle every 29 hours, process startup and shutdown are
> > monitored, the process is constantly pinged to make sure it is
> > running, the process handle is tracked and signaled when it terminates
> > unexpectedly, etc etc.
>
> > Realizing that recycling is a normal part of operations, IIS6 also
> > makes sure to isolate such recycling from the end user -- the end
> > user's TCP connection never terminates during a recycle, due to some
> > kernel-mode magic. Combined with user-mode application which stores
> > session-state out-of-process (like ASP.Net Session State Service), one
> > is virtually guaranteed reliable uptime with no user-visible data
> > loss, even if the web application crashes after processing every
> > single user request.
>
> > This is about as good as IIS6 can make it -- given an unreliable web
> > application, make it appear reliable to the end-user, and do it
> > without requiring any fixes of the unreliable web application.
>
> > Of course, not all unreliable application can be made to appear
> > reliable -- if so, then we are all out of jobs! -- but IIS6 sure tries
> > a whole lot more to be resiliant.
>
> > In your case, it just happens that the resiliancy has a side effect on
> > non-persisted user state, but it can be easily adjusted.
>
> > Assuming your web application never has a problem and stays with in-
> > process session state, you will want to change these defaults:
> > 1. Turn off the 29 hour periodic recycling
> > 2. Turn off the 20 minute idle timeout
>
> > This will prevent unexpected loss of session state.
>
> > Of course, if you ever use an application with out-of-process session
> > state, you can leave everything as the defaults and never notice a
> > difference in functionality nor reliability.
>
> > //David
> >http://w3-4u.blogspot.com
> >http://blogs.msdn.com/David.Wang
> > //
>
> > On Sep 11, 8:45 pm, "Don Miller" wrote:
> >> Thanks. I never had to do the "old IIS5 stop/start" with my web
> >> application
> >> that runs and runs ;)
>
> >> wrote in message
>
> >>news:1189522483.870348.119960@g4g2000hsf.googlegroups.com. ..
>
> >> > Don,
>
> >> > You do use session based cookies because ASP Sessions make use of
> >> > cookies. If not, how could IIS relate a given http request to its
> >> > Session property bag? :)
>
> >> > Given you have a 24/7 requirement, you still want to make sure IIS is
> >> > healthy, so monitor the resource usage (memory, CPU, etc...) closely.
> >> > If you see memory going up, then there is nothing left to do besides
> >> > recycling manually. Believe me that recycling in IIS6 will provide the
> >> > least damage and disruption compared to the old IIS5 stop/start.
>
> >> > Tiago Halm- Hide quoted text -
>
> >> - Show quoted text -- Hide quoted text -
>
> - Show quoted text -

Re: Default AppPool Recycling Question

Hi all,

I have the same problem.
Some customser reported about unexpected logouts. But I am not sure it
this is really the recycling mechanism.

One szenario:
- User logs in and surfs to five pages that you only can visit when you
are logged in.
- When going the 6th page the user is logged of (only 10 seconds between
page 5 an d page 6)
- User logs in again and goes on
- After 2 pages he is logged out again

Can this be the problem withrecycling?
Or do you have another idea?

Regards,
Thorsten


*** Sent via Developersdex http://www.developersdex.com ***

Re: Default AppPool Recycling Question

Look up documentation on "LogRecycleEvents" and make IIS log all
recycles.

If you see reports of unexpected logouts but do not see recycle
events, then your issue is not with recycling but something else,
likely specific to your user.

For example, it is possible the user comes from a proxy or other
networking device that could strip cookies or get confused between
network sessions and drop cookies, thus losing their session and
"logging out". There's nothing you can do about it on the server-side
-- the client is basically hosed.


//David
http://w3-4u.blogspot.com
http://blogs.msdn.com/David.Wang
//




On Sep 17, 7:42 am, T. Henke wrote:
> Hi all,
>
> I have the same problem.
> Some customser reported about unexpected logouts. But I am not sure it
> this is really the recycling mechanism.
>
> One szenario:
> - User logs in and surfs to five pages that you only can visit when you
> are logged in.
> - When going the 6th page the user is logged of (only 10 seconds between
> page 5 an d page 6)
> - User logs in again and goes on
> - After 2 pages he is logged out again
>
> Can this be the problem withrecycling?
> Or do you have another idea?
>
> Regards,
> Thorsten
>
> *** Sent via Developersdexhttp://www.developersdex.com***