views:

5472

answers:

6

I have been searching for info on this to no avail. The context of why i need this is another question I asked here. More specifically, does creating/updating/deleting files in App_Data cause a pool recycle?

If someone could provide a detailed list of what causes a recycle, that would be great.

UPDATE: As two users already noticed I would also be happy to an answer specifying reasons for recycling the AppDomain only and not the whole pool.

A: 

This can happen on a daily basis based on preferences, or when the max virtual memory for the process has been exceeded.

Ben Scheirman
I understand these causes. I was rather asking about what application (not IIS related) changed would cause a recycle.
Slavo
"changed" to be read as "changes"
Slavo
Ahh, ok. Changing the app_data folder shouldn't recycle, but you might consider writing to a log when the applicaiton_start happens so that you can tell for certain.
Ben Scheirman
That's what I'll do after I get a few responses here :)
Slavo
A: 

Agreed, sometimes this is very mysterious. You could run some simple tests to see. One test may be to write a simple page that adds a time-stamp to the Asp.net cache (System.Web.Cache). Once it is fully cached make the changes you're interested in (change a file in the app_code or app_data) then hit the page again.

If the pool recycled, your cached data would have gone with it.

Tim Merrifield
+4  A: 

Two different effects - the AppPool process is the host for potentially multiple appdomains. Typically this can be recycled by a number of effects e.g. time - every 'n' hours, lack of requests, memory use etc. Configured in IIS Config Manager.

AppDomain - the hosted instance of your application root, can be cycled more frequently without affecting other AppDomains in the AppPool. Tess' post on AppDomain recycling is pretty insightful

http://blogs.msdn.com/tess/archive/2006/08/02/asp-net-case-study-lost-session-variables-and-appdomain-recycles.aspx

You are writing to a folder monitored for recompilation - this will trigger the appdomain recreation at some point.

Event log will help you determine cause initiated the recycled.

stephbu
+3  A: 

The article you liked in the other post actually did a really good job of this.

Immediate Recycle

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

Delayed Recycle

Can occur with multiple changes in other locations, typically, I've only noticed this with changes to .aspx or .cs/.vb files though. Adding temporary text, csv or other files has not resulted in issues for me.

NOTE: These are all app-domain recycles, and not actual recycles of the pool. Typically the application POOL will only recycle based on settings in IIS (Number of requests, memory limit, idle time, or scheduled restart).

Mitchel Sellers
Thanks, Mitchel. But it doesn't say anything about App_Data in particular. While here is says all App_ folders: http://weblogs.asp.net/owscott/archive/2006/02/21/ASP.NET-v2.0-_2D00_-AppDomain-recycles_2C00_-more-common-than-before.aspx#440333
Slavo
Which one do I believe - these are exactly the inconsistencies, because of which I wasn't able to find one single answer.
Slavo
Slavo, this is true, however, I would be cautious as to the dates of the articles, as I know various service packs have modified this behavior at various points down the line.
Mitchel Sellers
A: 

This is a setting you can manipulate to recycle the app pool based on the number of minutes it has been running, or the number of requests it has processed.

It will also recycle on web.config changes and other things that have been posted here.

An IIS reset will also do the trick, as will stopping/starting services.

Milner
+5  A: 

You might want to turn on full AppPool Recycle Event logs:

cscript adsutil.vbs Set w3svc/AppPools/DefaultAppPool/LogEventOnRecycle 255

You also might want to take a look at this Scott Guthrie blog article: http://weblogs.asp.net/scottgu/archive/2005/12/14/433194.aspx that shows how to write code in Global.ASAX to log the actual cause of an Application.End event.

This has been extremely useful to us in diagnosing several screwy issues - one in partictual was an app that was writing log files to the wwwroot directory - too many file changes resulting in a recycle...

Christopher_G_Lewis
FYI: adsutil.vbs should already exist on the machine. On my machine, it lives in both c:\Inetpub\AdminScripts\ and c:\WINDOWS\ServicePackFiles\i386.
Jim G.