Support
Timesheet and IIS 6

Internet Information Server version 6 (IIS 6) is the web server that ships with all versions of Windows 2003. This version of IIS has a new feature that can undermine the stability of Journyx Timesheet™. Journyx is working on a change to Timesheet to keep the application stable with IIS 6. Until this change is released, Journyx recommends the following configuration changes to IIS to keep your Timesheet installation stable. At this time Journyx expects to implement this change in the Timesheet version 6 family.

The New Feature: Recycling

Within IIS all executable applications are assigned to Application Pools. Separate Application Pools help similar applications not interfere with each other. The Application Pools control the ways in which the executable applications run.

In IIS 6 Microsoft added a function called Recycling to the Application Pools. A recycle is just a fancy restart. Instead of stopping and restarting the core executable process of IIS; the recycle starts a second IIS process, moves all active processes that are connected to the existing IIS process to the new one, then stops the initial IIS process. Unfortunately not all of the processes connected to the initial IIS process appear to always get moved to the new process. Also, when the initial process is stopped it doesn't report the stoppage to any dependent processes, on the assumption that the dependent processes will have been moved.

The Problem

When IIS 6 recycles itself it sometimes locks up Timesheet, whenever Timesheet processes (database daemons) don't get moved to the new IIS process correctly. In our testing it appears that if a user's page request in Timesheet comes in during the few seconds that IIS has 2 processes running then the page request will go to the old IIS process. So as long as the recycle is scheduled for times when no users will be accessing Timesheet then Timesheet has no problems continuing on after the recycle.

When it occurs that the recycle event happens to exactly coincide with a Timesheet application page request, Timesheet silently freezes. There are no error messages generated. There are no tell-tale signs. The Timesheet web pages simply do not reply until you restart Timesheet service on the server. Restarting Timesheet always fixes the problem immediately. However the circumstances of the problem are such that it only really occurs when the application is very busy. Then lots of end-users get blank pages in Timesheet until someone restarts the service.

The IIS Configuration Fix

So the problem should be infrequent but severe. The good news is that it is easily avoided. Microsoft included a simple interface to control the timing of the recycle events. As shown in this image, in the IIS management console there is a folder of Application Pools.

Find the Application Pool that lists Journyx Timesheet in the right-hand window. Usually, but not always, this is the 'Default App Pool'. Right-click on the Application Pool and select 'Properties'. The first tab of the Properties window is the 'Recycling' tab.

The first check-box is 'Recycle worker process (in minutes)'. This box appears to always be checked by default, and the default time setting appears to be 1740. Different versions of Windows 2003 may have different default settings. We do not know why Microsoft chose to recycle their IIS core process every 29 hours, but we do know that it makes it difficult to isolate that recycle event as the cause of a problem in a worker application.

No version of IIS prior to IIS 6 had this recycling feature. So whatever memory leaks or other issues that Microsoft is hoping to address must not be overly critical, or they would certainly have fixed this earlier or back-ported the feature to older IIS versions. Timesheet runs stably under older versions of IIS where the recycle event is not an option. Timesheet database daemons dynamically restart themselves as appropriate. Those restarts occur daily (or hourly during peak usage). So IIS's recycling feature is not going to effect Timesheet other than possibly freezing it up. If Timesheet is the only application/site running on this server then you should be completely safe in just turning off the recycling.

If you want to use the IIS Application Pool recycling, then you can schedule it to occur when Timesheet is going to be idle. Or you could disable recycling and schedule an event to stop and restart the IIS Admin service and then stop and restart the Timesheet service. If you are going to schedule nightly or weekly backups of Timesheet then you may choose to schedule the recycle to occur just before the backups. If you do that then you will want to schedule an event to stop and restart the Timesheet service after the backup completes, just in case.

The Timesheet database backup utility (backupdb) does not use the web interface's database daemons, it makes its own direct connection to the database, so it is immune to the effects of this IIS recycle freeze.