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!
eval() is not necessary. This will work fine:
var date = new Date(parseInt(jsonDate.substr(6)));
The substr() function takes out the /Date( part, and the parseInt() function gets the integer and ignores the )/ at the end. The resulting number is passed into the Date constructor.
I have intentionally left out the radix (the 2nd argument to parseInt); see my comment below.
Also, I completely agree with Rory's comment: ISO-8601 dates are preferred over this old format - so this format generally shouldn't be used for new development.
For ISO-8601 formatted JSON dates, just pass the string into the Date constructor:
var date = new Date(jsonDate); //no ugly parsing needed; full timezone support
Best Answer
In IIS 6, go to the Application Pools section, and right-click > Properties on the pool which hosts the ASP.NET application in question. Go to the Performance tab and uncheck "Shutdown worker processes after being idle for:"
In IIS 7, go to the Connections pane and find Application Pools, and select Advanced Settings for the pool which hosts your application. Find the "Idle Timeout" property and set it to "0" (this disables it).
The default is 20 minutes of inactivity. By unchecking the box, once your AppDomain is loaded by the worker process, it will never die (unless you kill the process or something of course). By default, IIS will recycle the process when it reaches some limit, such as a memory cap, but it will also start a new one and "phase over" all incoming requests until the old one is unused, so as to minimize disruption.
I've also written a small c# class which will keep your ASP.NET application alive (alternate archived version) under normal circumstances. Since it runs within the application, obviously it can't stop IIS or anything else from explicitly killing the process, but it will keep the application "hot", e.g. the app will never go idle long enough for IIS to decide to shut it off.
If you do not have direct control over your IIS configuration (shared host, for example) your best bet is to have a small application running on a separate system - say, an always-on workstation - which hits your site every x minutes to keep the application pool from timing out. Nothing fancy - a simple WebRequest and a while() loop in a console application will do.