What is the difference between DefaultAppPool and Classic .NET AppPool in IIS7?

Question

I have a problem with timeouts in IIS. In the web.config the session timeout was set to 60 minutes but after 20 minutes the session ends.

This problem only occurs in IIS7 and not in IIS5.

After some investigation, I discovered it was due to the application pool's timeout. If the App Pool is left 20 minutes without doing anything, IIS ends and session.

If the application is using the defaultAppPool this always happense but if I change the App Pool to the classic .NET App Pool, the timeout does not occur.

Both of modes have idle timeout but only in the DefaultAppPool does this occur.

• Why is this?
• What is the difference between be a Classic .NET AppPool and DefaultAppPool?
• What is the difference in the pipeline, between Classic and Integrated?

Answer 1

I am not sure but I think might be the way IIS handles the event handlers. I could very well be wrong and I am actively searching for an answer. When I find a better answer I will post it.

Answer 2

The classic pool processes the requests in the app pool by using seperate processing pipelinesfor IIS and ISAPI. integrated uses an integrated pipeline, IIS and ASP.NET a(better performance) takes advantage of the improved features of IIS 7.0 using only the one process. Good practise is to create a new application pool for each application, then configure sepeerately according to application requirements.

Classic follows the steps below : 1.The incoming HTTP request is received through the IIS core.

2.The request is processed through ISAPI.

3.The request is processed through ASP.NET.

4.The request passes back through ISAPI.

5.The request passes back through the IIS core where the HTTP response finally is delivered

integrated uses:

1.The incoming HTTP request is received through the IIS core and ASP.NET.

2.The appropriate handler executes the request and delivers the HTTP response

Increase the session timeout in web.config as per

remember increasing this causes the application to consume more resource, eg memory

Answer 3

I think your question has the answer in it. IIS 6 and 7 have a concept of Application Pool timeout, this is different from session timeout.

What is the difference between modes ... already addressed. I'm uncertain about how your questions regarding pipelines and differences in modes relate to your problem - the timeouts.

Some perspective: Idle timeout won't occur on a web site with any traffic. You've probably got a problem that only occurs in a QA site or your dev box. The idle timeout setting exists to save resources on your dev box and $5/month hosting companies with lots of underused web sites (e.g. my blog). You probably do not want idle timeout on a public site.

Session timeout - set in web config, if a user doesn't hit the server, their session times out.

Idle timeout Noone touches the web server at all for 20 minutes, so shut down to save resources. In IIS 6, this is on the performance tab of the app pool - and is easy to disable. In IIS 7, you can set in in application pool advanced settings or in the processModel element. I don't run as much IIS 7 as IIS 6, but it looks like removing the element from web.config, or setting to 0, gets infinite idle timeout.

Answer 4

The DefaultAppPool ignores settings for session timeout in web.config, but ASPNet App Pool will use the settings in web.config.

Answer 5

IIS7 has some major changes to better support WCF and one of the key pieces is the new integrated application pool. This session from PDC talks about some of these challenges from the perspective of making WCF services perform better: http://channel9.msdn.com/pdc2008/TL38/

This page has a good overview of IIS7 architecture: http://learn.iis.net/page.aspx/101/introduction-to-iis7-architecture/. I've included some of the key information from this article on the purpose of the two different kinds of app pools below:

Integrated application pool mode

When an application pool is in Integrated mode, you can take advantage of the integrated request-processing architecture of IIS and ASP.NET. When a worker process in an application pool receives a request, the request passes through an ordered list of events. Each event calls the necessary native and managed modules to process portions of the request and to generate the response. There are several benefits to running application pools in Integrated mode. First the request-processing models of IIS and ASP.NET are integrated into a unified process model. This model eliminates steps that were previously duplicated in IIS and ASP.NET, such as authentication. Additionally, Integrated mode enables the availability of managed features to all content types.

Classic application pool mode

When an application pool is in Classic mode, IIS 7.0 handles requests as in IIS 6.0 worker process isolation mode. ASP.NET requests first go through native processing steps in IIS and are then routed to Aspnet_isapi.dll for processing of managed code in the managed runtime. Finally, the request is routed back through IIS to send the response. This separation of the IIS and ASP.NET request-processing models results in duplication of some processing steps, such as authentication and authorization. Additionally, managed code features, such as forms authentication, are only available to ASP.NET applications or applications for which you have script mapped all requests to be handled by aspnet_isapi.dll. Be sure to test your existing applications for compatibility in Integrated mode before upgrading a production environment to IIS 7.0 and assigning applications to application pools in Integrated mode. You should only add an application to an application pool in Classic mode if the application fails to work in Integrated mode. For example, your application might rely on an authentication token passed from IIS to the managed runtime, and, due to the new architecture in IIS 7.0, the process breaks your application.