简体   繁体   中英

IIS application pool ignores Shutdown Time Limit (seconds) with c# application

Shutdown Time Limit (seconds) - problem

I have an asp.net web form application that needs to save in-memory Db on disc before it ends(triggered by recycling at specific time). The time for saving the db is now growing and it sometimes takes more than 5 minutes.

I have increased "Shutdown Time Limit (seconds)" time for my application pool to 10 minutes but it did not help. If IIS triggers recycling event or I do it manually it always finished after 5 minutes.

Proof from log file

2016-04-20 19:03:44.1431 - INFO [9588]: Application_End
2016-04-20 19:03:44.1431 - INFO [9588]: Delay saving to total 444 seconds
2016-04-20 19:03:45.1462 - INFO [9588]: Delay 1 second passed
.
2016-04-20 19:08:45.1762 - INFO [9588]: Delay 301 second passed

301 second is the last line from the log.

In order to eliminate any side effects I have created a new empty asp.net web app.( .NET 4.5) I use only simple method that logs every second a new line and I am able to reproduce the same behavior.

using System;
using System.Configuration;
using System.Linq;
using System.Threading;
using NLog;

namespace DemoApplicationLog
{
    internal static class Log
    {
        public static Logger Instance { get; private set; }
        static Log()
        {
            LogManager.ReconfigExistingLoggers();

            Instance = LogManager.GetCurrentClassLogger();
        }
    }

    public class Global : System.Web.HttpApplication
    {
        protected void Application_End(object sender, EventArgs e)
        {
            Log.Instance.Info("Application_End");
            DelaySavingBySeconds(ConfigurationManager.AppSettings["DelaySavingBySeconds"]);
        }

        private static void DelaySavingBySeconds(string interval)
        {
            Log.Instance.Info($"Delay saving to total {interval} seconds");

            var value = ConfigurationManager.AppSettings["DelaySavingBySeconds"];
            if (string.IsNullOrEmpty(value))
            {
                interval = "0";
            }

            var intervalInSeconds = Convert.ToInt32(interval);

            foreach (var second in Enumerable.Range(1, intervalInSeconds))
            {
                Thread.Sleep(1000);
                Log.Instance.Info($"Delay {second} second passed");
            }

            Log.Instance.Info("Delaying passed!");
        }
    }
}

Tested on: win 7, IIS 7.5.7600.16385 win 2012R2, IIS 8.5.9600.16384

I have set up a new application pool with .NET CLR Version v4.0

Facts I can reproduce

  1. "Shutdown Time Limit" is ignored, if the value is greater than 5 minutes (300 sec.)
  2. "Shutdown Time Limit" works fine, if the value is lesser than 5 minutes
  3. If I change anything in the Web.config file and IIS recycle(caused by the change), application is NOT terminated after 5 minutes.

Is it IIS bug or what could be possibly wrong?

Thanks Petr

The demo web app is available on github

Like many developers I have had may share of IIS Pools shut downs, and Worker Process Recycling issues. Instead of tweaking any settings in IIS there are a couple of approaches that can keep the process alive as your save time gets longer and longer.

I will share something I have done on many sites to get rid of the headache of IIS recycles.

(1) One particular site I run a batch process in IIS in an ASP.NET Thread. It can run from 15 minutes to 1/2 hour. In that particular case I will ping the URL of of the site every 10 minutes to keep the worker process alive.

(2) Another case, I developed interally facing sites and the users do not want to log out or get timed out. In this case place a hidden iFrame on the page, and have JavaScript post that page back every 15 minutes. This worker process will never shut down. It sounds like this example may work for you.

The technical post webpages of this site follow the CC BY-SA 4.0 protocol. If you need to reprint, please indicate the site URL or the original address.Any question please contact:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM