IIS 7.5 - Disable Overlapped Recycle property not being obeyed when web.config is updated

6,143

From this MSDN Post: https://blogs.msdn.microsoft.com/tess/2006/08/02/asp-net-case-study-lost-session-variables-and-appdomain-recycles/

So as part of your code deploy process, it looks like your pool will recycle when you deploy any one of these changes:

Immediate Recycle

  • Web.config changes
  • Machine.config changes
  • Global.asax changes
  • Bin directory changes
  • App_Code changes

(borrowed from: https://stackoverflow.com/questions/302110/what-causes-an-application-pool-in-iis-to-recycle )

Share:
6,143
John
Author by

John

Updated on September 18, 2022

Comments

  • John
    John over 1 year

    I have a site which holds an exclusive lock on some resources. I used the .NET Application_Start and Application_End events to acquire and release the lock on these resources at the appropriate time. For this to work properly, there can only ever be one instance of my application running at any given time.

    To get this to happen, I've set the Disable Overlapped Recycle property on the Application pool to True. This property is supposed to ensure that the old worker process shuts down completely before a new one starts up whenever the app pool is recycled. This works fine whenever the app pool is recycled manually through IIS, automatically as the result of the idle-timeout being reached or automatically according to any specific time/time interval rules.

    However, when the web.config for the site is updated, this rule isn't getting applied - A new worker process starts up before the old one finishes shutting down. This causes bad things to happen. I have the Disable Recycling for Configuration Changes property set to False as I do want the app pool to get recycled when the web.config is updated - this happens frequently during development.

    Is this something which is expected, or is it a bug in IIS? IS my only option to set up so that changing the web.config doesn't recycle the app pool? I'd rather not do this, since I'm pretty sure it will cause many headaches with people changing the configuration and then forgetting to recycle the app pool.

    Update:

    To be more clear, when the new worker process start event is called before the old worker process has finished shutting down, then the old worker process end event never gets called - It doesn't happen out of sequence, it never happens at all.

    • Greg Askew
      Greg Askew about 11 years
      How long after the web.config is updated before the new worker process is started?
    • John
      John about 11 years
      The new worker process starts as soon as I try to access the site after a recycle - So less than a second if I'm quick. If left, the old worker process 'shutdown' event takes places 20-30 seconds after the recycle.
    • Andrew Rimmer
      Andrew Rimmer about 10 years
      I have the same issue. There is overlap
    • lesscode
      lesscode almost 10 years
      Similar problem, but with "Disable Recycling for Configuration Changes". When I set this to true, when I change the web.config, my WCF ServiceHost closes. The w3wp process stays up, and my ServiceHost spins up again on the next client request. I assume that "Recycling" here means the application domain, not the application pool (process), but if so the configuration option on the app pool doesn't seem to have any effect at all. How can I prevent changes to configuration from "recycling" service hosts in this way?
    • kheld
      kheld over 9 years
      Editing the web.config file causes the appDomain to reload. The appDomain is seperate from the AppPool. You should not see a new W3WP process id just from changing the web.config. See here treeloop.com/blog/iis-application-domain-and-pool-recycling
    • Sam Cogan
      Sam Cogan about 9 years
      @kheld is absolutely right (perhaps add this as answer) this is not an appool overlap, it is an appDomain overlap. I don't believe you can stop this, but you can disable app domain recycling on change.