I have a web service that creates a thread to process some data in the background. I've seen a "System.Threading.ThreadAbortException: Thread was being aborted" message in one of my logs where the thread was killed. I am currently under the assumption that the thread will run as long as it takes to execute the tasks that it's working on, however after googling the exeception I've seen several posts making mention of increasing the ExecutionTimeOut property of the application in the web.config file. My question is:
What is the maximum execution time of a thread executed in ASP.NET? Is this timeout unlimited or still bound by the ExecutionTimeOut property of the application?
This is a similar question.
How to know who kills my threads
You can run it as long as the pool is running. If the pool thats keep the thread is restart then its wait for all the threads to exits, but the web service to run the pages stop working at this moment, and you have problems. Also if you have setup your pool then in pool recycle if the thread is not stop after some time its kill it.
In My program one index thread it was running for more than 26 hours doing hard database work, and was on static function.
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.
In my web site, I turned off recycling on app pool recycling settings. I was wondering if worker process is still releasing its memory even though recycling is turned off? Since I turned off recycling, the memory usage by the web site is increasing without a limit. Does worker process create a new thread for each request? If so does each thread get killed after it serves the request?
Yes, each request causes a new thread to be created or taken from the thread pool. The number of worker threads available per processor is governed by the maxWorkerThreads in the processModel section of the web.config. The range for this value is 5 to 100, with the default value being 20.
So the answer to your question is that each request gets its own thread and if none are available, then the request is queued up and processed once a thread is available. The thread is not necessarily killed when the request finishes, because it may return to the thread pool.
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.
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?
we have a scenario where in whil serving one asp.net request from iis from our code we have created a child thread from thread pool to servve some background task.the idea was to finsih the main thread wihich is processing the request without depending on our child thread task. But our doubt is while processing a request in asp.net will workerprocess wiat untill the thread finishes its task ?
No, if you've created a separate thread and don't have any code to wait on it, the request will certainly complete.
What I don't know is whether a worker process can be recycled while there are non-ASP.NET thread pool threads executing. I strongly suspect it can - so be aware that your child task could be terminated at any point. If this is a problem, you may wish to create a non-threadpool foreground thread.
No, the background thread will not wait for the main thread to finish, it will start immediately. If you use the Thread pool your task may have to wait for a thread to be available, but that is all.
You should however be aware that this may not be a good solution, for the application domain your asp.net site is running in may be recycled while your background thread is running. This will kill the background thread leaving the task incomplete. If it is possible, you should separate the background task into a service application that runs in a separate process. This will ensure that the task isn't killed while running.