Will the automatic recycling of the application pool in IIS kill a working thread that was called from QueueUserWorkItem in ASP.NET?
Since this happens at set intervals and I'm getting random errors it would appear, I am wondering if these two are running into each other?
If so, how do I run an asynch task and not get killed by a recycle?
When ASP.NET recycles, any long-running tasks within the ASP.NET process will be stopped. If you need to run background tasks then create a companion windows service to host these separate tasks.
It depends on what kind of recycling settings you have set on the application pool. Assuming you have set recycling at a specific time [or any other condition for that matter!]... at that time a new Worker Process will be spawned, and the existing worker process will have 90 seconds to do what it was supposed to do. After that 90 seconds, whatever is present in the process would be gone.
You said it happens at set intervals. Have you set time based recycle in IIS?
Related
I'm running a very high traffic site that gets a good 300+ requests/second (http://cooltext.com). A restart takes a good 90 seconds at least for it. So every time I post a new build it goes down for a minute or two. Long enough to trigger my monitoring services.
When I make a change that restarts the server, it appears that the restart stalls until all of the old requests on the old application pool (some of them very long running) complete. I can make the restart happen much faster by killing the old w3wp.exe instance manually.
Is there some way to force IIS to close all the connections right away and do a hard restart? Some setting in IIS or asp.net to control this?
Just found the following that appears to be what I'm looking for: http://msdn.microsoft.com/en-us/library/aa720127(v=vs.71).aspx
Shutdown Time Limit is the equivalent application pool setting for the shutDownTimeout ASP.NET process model setting. It specifies the amount of time a worker process is given to shutdown gracefully. If the worker process does not shutdown in time amount specified, the ASP.NET ISAPI will end the worker process. Shutdown Time Limit is set to 90 seconds by default. You can specify a different time limit by changing the value in the spin box.
I'm troubleshooting restarts in an ASP.NET application. The application is restarting about 20 times a day. We strongly suspect one part of the application because the restarts began when this particular feature when into production. I've added some logging to those pages using the log4net library, but I'm having trouble interpreting the logs.
When an ASP.NET application is running in an Application Pool, does only a single instance of that application run, or will multiple instances of that application run? I know several worker process threads will be spawned. What is the relationship of the worker process threads to the application(s) running in the App Pool?
I am thinking that I may not be interpreting the results correctly if there are multiple applications logging to the same log. If one is restarted but the other is not, the logs aren't really telling me much about what was happening when the restart occurred.
UPDATE 1
Looking at this page, I find the following information:
An application pool defines a group of one or more worker processes, configured with common settings that serve requests to one or more applications that are assigned to that application pool. Because application pools allow a set of Web applications to share one or more similarly configured worker processes, they provide a convenient way to isolate a set of Web applications from other Web applications on the server computer. Process boundaries separate each worker process; therefore, application problems in one application pool do not affect Web sites or applications in other application pools.
But I am still confused. I know from experience that I can assign two entirely different applications to use the same App Pool. Does that mean that exactly two worker processes will be spawned? Or can there be multiple worker processes spawned for the first app, and multiple worker processes spawned for the second app? If a problem happens in one worker process, can it take down every application running in that App Pool?
UPDATE 2
From this page about using WinDbg, I found this information (emphasis mine):
In IIS 5.x, there is only one Aspnet_wp.exe worker process and one debugger thread. Consequently, only one debugger can be attached to the Aspnet_wp.exe process at a time. This can pose a problem if you're dealing with multiple Web applications on the same machine. In IIS 6.0, you can coerce an AppDomain to run in a separate application pool. (For more information, see "IIS 5.x Process Model" and "IIS 6.0 Process Model" in Chapter 1.) Separate application pools provide multiple W3wp.exe processes. Multiple debugger threads are created in these processes (one in each), allowing you to debug more efficiently.
This sounds to me like each App Pool gets one w3wp.exe process. Am I interpreting that right? And if so, does that still apply in IIS 7.5?
Yes, each application pool is typically a single process1, but can contain multiple threads. You can assign multiple sites to an application pool, and those sites will all run under the same process, however they will run under different "app domains", which are security contexts that separate the code of one site from another, even if they're running on the same app pool.
Two users hitting the site at the same time can run on different threads, meaning they can run concurrently. That means any logging can have values interspersed. You might want to add a session value to your logging so you can sort based on session.
App pool restarts (recycling) are normal, 20 restarts in a day does not seem unusual. They can happen multiple times per day, and IIS controls when app pools are restarted. It does this whenever it feels it needs to clean up the pool.2 Your applications should be written in such a way as to recover gracefully from this (ie, do not keep anything in session that cannot be easily recreated if the app pool restarts).
The app pool can also restart when an unhandled exception occurs in your app. In that case, you want to address the cause of this. Such exceptions are usually logged in the event log.
1 – While you can configure an application pool to have multiple worker processes (this is known as a Web Garden), this is not a typical (nor generally recommended) configuration in my experience.
2 – Note that using IIS Manager you can configure an application to log recycle events to the Windows Event Log. You can also use IIS Manager to set the threshold for when several of the different types of recycle events occur.
The thread will be started on each Application_Start event.
It will be a monitoring thread which is supposed to run constantly.
So even if the app shuts down, once it is restarted the thread will start too ensuring it runs all the time.
However I need to be sure that this thread will not be stopped / shut down while the application is running.
So in a few words, does anybody know if asp.net could shut down such a thread without actualy stopping / recycling the application.
As a matter of design, you shouldn't depend on asp.net to run threads like this. Little things like app recycling can cause you a lot of trouble.
Instead, create a windows service to execute the thread. This way you don't have to worry about it.
Update
I just wanted to add a little more information.
IIS has the ability to execute your app across multiple threads and processes. A standard site installation usually only has a single process (aka: web garden) assigned which spins up around 20 threads to handle request processing.
However, any IIS administrator can easily add more processes to the mix. They usually do this when a site can hose a single process either because request processing takes too long, or the number of handler threads isn't enough, or as a temporary measure if the app has enough problems that a single thread will hose the entire process fairly often.
If you have a thread being spun on app start, then it will create one for each worker process the site has. This may be unexpected behavior to you or your successors.
Also, monitoring apps are almost always completely separate to the application they are monitoring. One of the primary reasons is that in the event the monitored process dies, hangs, or otherwise becomes unresponsive then the monitoring app itself still needs to carry on and log this information. Otherwise the monitored process could very well hose the monitoring app itself.
So, do yourself a favor and move this to its own process. The best way to do this on an IIS server is to create a windows service and give it the appropriate execution rights to do what you need.
After deploying an ASP.Net application to a new server, the first user to hit the app gets a long pause, presumably because the app is performing its initial compilation. However, this pause seems to also also occur after the application has timed out and unloaded itself from memory.
The first compilation would be tolerable as it only happpens once, but the 2nd one seems to me like it should be unnecessary....is there a workaround to address this issue? It would be nice to be able to extend the application timeout, but I only see a way to extend the session timeout, which I would rather not do, as this would keep all user sessions in memory for a long period of time.
That's IIS shutting down the worker process - the default is a 20 min idle time. In IIS6, you can configure the app pool and turn off the Idle timeout (on Performance tab). In IIS7, it's in the Advanced Settings.
A common way (though looks hackish to me) to keep the worker process alive is to have some program issue web requests to some URL in the application on a regular basis.
You can reduce the initial startup time by precompiling the ASP.NET app with aspnet_compiler.exe. This won't reduce the initial request time to zero (it'll still need to create the worker process and do other housekeeping.) but it'll noticeably reduce it.
I did find some recommended settings for the App Pools in IIS. The intended outcome of these settings is to reduce the number of times your application needs to go through the startup cycle. These settings should apply to IIS 6 as well as IIS 7:
Recycle Worker Process: Disable. Use this only if you have multiple websites and are trying to isolate processes.
Shutdown worker processes after being idle for (time in minutes): Disable unless you are sharing resources on your server. With this setting disabled, your website should not unload, ensuring that startup time for your site is as minimal as possible.
How can I overcome a slow loading application with several app pools in IIS 7 ?
And not have requests wait for the server to load (in case of recycling) and create a queue. But have the server loaded while hitting recycle condition before the first requests arrives.
Thanks,
Oshrat.
Are you sure the slow load isn't a result of waiting for the original pool to complete? This can happen if the app pool has the "Disable Overlapped Recycle" setting turned on.
Applications will load their initial state when the get the first request. Hence you could consider having a little tool whose job it is to ping the application to get it to start before a real user attempts to use it.