• Choose a category
• All
• Classic-Fiction

There are many reasons for a recycle of the worker process to be triggered. Natural reasons are those configured through the wizard shown in Figure 2-18.

Figure 2-18. Application pool recycling settings.

The application pool can be recycled at regular intervals (which is the default choice, as shown in Figure 2-18), after serving a fixed number of requests, at specific times, or when enough memory is consumed. Beyond this, the pool is recycled when you apply changes to the deployed site and modify configuration files or the Bin folder. If you frequently update bits and pieces of the site (for example, you published it as a Web site), an application restart also happens when a given number of assemblies is loaded in memory.

In the .NET Framework, you can’t unload a given assembly. Therefore, when an ASP.NET page is modified, it is recompiled upon the next access, resulting in a new assembly being loaded in the AppDomain. The number of recompiles allowed is not unlimited and is controlled by the numRecompilesBeforeAppRestart attribute in the section of the configuration file. When the maximum number of recompiles is exceeded, the application just restarts.

Unexpected Restarts

Aside from all these reasons, an application pool can recycle because of unhandled exceptions, timeouts, low memory, or threads or connection pool issues. In general, the worker process recycling is a defensive measure aimed at keeping the application in shape and preventing any worse troubles. An application restart is not free of issues because it causes the user’s session to disappear, for example; however, that is probably the lesser evil compared to having a site that hangs or crashes.

An application restart is not something you can spot easily. It manifests through diminished and periodical responsiveness of the site. Diagnosing the cause is usually hard. When you suspect undue process recycling, the first place to look is in the event viewer to see whether some interesting information is being tracked. Memory usage is another good successive area to investigate.

In IIS 7.x, you can use the settings shown in Figure 2-19 to determine which event log entries you want to be generated in the case of process recycling events.

Figure 2-19. Setting up event log entries for process recycling.

To make sure you track effective termination of the application, or to handle that in a customized way, you can resort to using the following code, adapted from an old but very nice post by Scott Guthrie:

public static class HttpApplicationExtensions

{

public static void TrackAppShutdown(this HttpApplication theApp)

{

// Use reflection to grab the current instance of the HttpRuntime object

var runtime = typeof(HttpRuntime).InvokeMember("_theRuntime",

BindingFlags.NonPublic | BindingFlags.Static | BindingFlags.GetField,

null, null, null);

if (runtime == null) return;

// Use reflection to grab the current value of an internal property explaining the

// reason for the application shutdown

var messageShutdown = runtime.GetType().InvokeMember("_shutDownMessage",

BindingFlags.NonPublic | BindingFlags.Instance | BindingFlags.GetField,

null, runtime, null);

// Log an entry in the event viewer (or elsewhere ...)

if (!EventLog.SourceExists("YourApp"))

EventLog.CreateEventSource("YourApp", "Application");

var log = new EventLog { Source = "YourApp" };

log.WriteEntry(messageShutdown, EventLogEntryType.Error);

}

}

Written as an extension method for the HttpApplication object, the method can be invoked easily from the Application_End handler in global.asax, as shown here:

void Application_End(object sender, EventArgs e)

{

this.TrackAppShutdown();

}

The result is an entry written in the application log for each restart. It’s not a magic wand, but it’s a nice extension you can incorporate into all applications or just in case of problems.

Output Caching Settings

Devised in the context of earlier versions of ASP.NET, output caching in IIS 7 is a fully fledged feature of the Web server.