What exactly is Appdomain recycling

I am trying to figure out what exactly is Appdomain recycling? When a aspx page is requested for the first time from a DotNet application, i understand that an appdomain for that app is created, and required assemblies are loaded into that appdomain, and the request will be served. Now, if the web.config file or the contents of the bin folder, etc are modified, the appdomain will be "recycled". My question is, at the end of the recycling process, will the appdomain be loaded with assemblies and ready to serve the next request? or a page has to be requested to trigger the assemblies to load?.

Solution 1:

Well, I think the thread was getting smoothly to a final conclusion, but in the end, it was otherwise.

I'll try to answer the question based on my understanding and leveraging what i've just read about in other web sites.

First of all, I myself try to avoid the term recycle other than for Application Pools since this may render someone confused. Now, getting to process, pools and AppDomain, I see the picture as follows:

An Application Pool is, in short, a region of memory that is maintained up and running by a process called W3WP.exe, aka Worker Process. Recycling an Application Pool means bringing that process down, eliminating it from memory and then originating a brand new Worker Process, with a newly assigned process ID.

Regarding Application Domains, I see it as subsets of memory regions, within the aforementioned region that plays the role of a container. In other words, the process in memory, W3WP.exe in this case, is a macro memory region for applications that stores subset regions, called Application Domains. Having said that, one process in memory may store different Application Domains, one for each application that is assigned to run within a given Application Pool.

When it comes to recycling, as I initially told, it's something that I myself reserve only for Application Pools. For AppDomains, I prefer using the term 'restart', in order to avoid misconception. Based on this, restarting a AppDomain means starting over a given application with the newly added settings, such as refreshing the existing configuration. That happens within the boundaries of that sub-region of memory, called AppDomain, that ultimately lies within the process associated with a respective Application Pool. Those new settings may come from files such as

web.config, machine.config, global.asax, Bin directory, App_Code,

and there may be others.

AppDomain are isolated from each other, that makes total sense. If not so, if changes to a web.config, let's say, of application 1, requited recycle of the pool, all other applications assigned to that pool would get restarted, what was definitely not desired by Microsoft and by anyone else.

Summarizing my point,

• Process (W3WP.exe)
  • AppDomain 1
  • AppDomain 2
  • AppDomain 3
  • AppDomain n

n = the number of assigned applications to the Application Pool managed by the given W3WP.exe

• Processes are memory regions isolated from one another
• AppDomains are sub-memory regions isolated from one another, within the same process
• Global IIS settings changes may require Application Pool recycle (killing and starting a new Worker Process, W3WP.exe)
• Application-wide settings changes AppDomains concerns, and they may get restarted after changes in some specific files such as the ones outline above

For further information, I recommend:

http://blogs.msdn.com/b/david.wang/archive/2006/03/12/thoughts-on-iis-configuration-changes-and-when-it-takes-effect.aspx

What causes an application pool in IIS to recycle?

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

Regards from Brazil!

Solution 2:

Take a look at this - that might explain it:

http://weblogs.asp.net/owscott/archive/2006/02/21/ASP.NET-v2.0-2D00-AppDomain-recycles_2C00_-more-common-than-before.aspx#440333

In general. What is called "first hit" on an ASP.NET Website is usually taking longer time, due to compilation, and creation of an AppDomain.

Whenever you deploy a site - make sure to use the "Publish Website" function in Visual Studio, to pre-compile your website. Then the "first hit" penalty is reduced. And remember to set the configuration to Release, and not Debug!

Solution 3:

Recycle shuts down the process hosting the appdomain. You'll notice that the PID changes when you recycle it.

Unloading the AppDomin simply unloads all of the assemblies in the AppDomain, which can then be reused.

The important thing to remember is that once the CLR is loaded into a process, it can't be removed. So if you needed to do something as soon as the CLR is loaded, then simply unloading the AppDomain won't help, because the CLR won't be reloaded.

Also not that IIS isn't the only process which can host the AppDomain - any process can, and you don't always want to kill the whole process just to unload your assemblies.