I'm using VS2010 and ASP.NET 4. I have a single, long-running background thread running in the application, which is designed to 'cleanup' the least recently used files in a folder. It uses an EventWaitHandle to eliminate uneeded CPU usage, but stays running for the life of the app.
After 24-40 deletions or so, the application restarts. This happens under both IIS Express and the WebDev server, with the debugger attached. No exceptions are thrown on the background thread, but a ThreadAbortException occurs on all threads, and the app restarts. No Redirect calls are made anywhere.
These files are located in an 'imagecache' folder in the root, not any folder that should cause a app restart. No folders are created or deleted.
The restart seems to occur a timed interval after a certain threshold of deletions occur.
Any idea why this is happening and how I can stop it? Restarting every 10 seconds ins't acceptable for me :)
Perhaps it's an IIS application pool recycle ? Have a look on the recycle settings to see if it might be something there.
Another option depends on how you start the background thread. If it's from an aspx page then it might be the Request thread timing out. If it's from the global.asax then this is not an option.
An asp.net application is to service client requests, not to run background tasks (although there are many kludges that allow this).
Can you put the thread into a service?
Related
I have a deployment workflow for an ASP.NET web app which begins with puttin an app_offline.htm file to the directory of my web app. Despite that, I usually get this error:
The process cannot access the file ... because it is being used by
another process.
Indicating that the IIS process is still running despite the fact that the app_offline.htm file is in place. If I remote desktop to the server and do a manual iisreset or shut down IIS with its GUI (or just wait a few minutes after manually putting the app_offline.htm file there, then the workflow works correctly.
So, how long does it take for IIS to shut down after app_offline.htm is in place?
I don't know but I would like to know. So I ran some tests...
The effect is pretty much immediate, but it may take some time for the IIS app to actually shut down due to extra clean up code. Expect files to be locked for some time even after app_offline.htm is in effect.
The actual file system event information takes just a few milliseconds to propagate.
The default is (up to) 90 seconds. This is defined in the application pool settings that your web application is running under in IIS as "Shutdown Time Limit".
Process Model documentation at Microsoft
We are encountering a strange phenomena in our production environment, every few hours the application kicks all users out by ending their sessions with Session_End event and fires Application_End event.
In our log, all the user's sessions are closed on the same mill-second.
We encountered this problem in our Test environment but only on rare occasions, and we could not duplicate this.
Everything else seems fine, other application running on this server works fine, there is no memory leak or CPU overuse. The application is based on ExtJS version 3.3, NHibnernate 3.2 and ASP.NET 4.0.
It doesn't seems like a Timeout error, some of the users worked for only several minutes before the session end.
Has anyone encountered similar problems?
There are a couple of reasons why an application pool recycles (and thus ends all open sessions and ends the application). See http://blogs.msdn.com/b/johan/archive/2007/05/16/common-reasons-why-your-application-pool-may-unexpectedly-recycle.aspx for a complete overview.
We had a similar problem in a production environment once. The reason for the recycle was the virus scanner that touched the web.config on each scan which made the application pool recycle. Try to disable the virus scanner on the server or exclude the application directory in the virus scanner.
Altering the following files will also trigger an immediate restart of the application pool:
web.config
machine.config
global.asax
Anything in the bin directory or it's sub-directories
This post: http://weblogs.asp.net/scottgu/archive/2005/12/14/433194.aspx gives you a way to catch the application end event with more detailed logging. This might help you to find the cause of the recycle.
Having a bit of a problem with my hosted ASP.NET applications. I noticed slowness when opening pages, the kind of slowness that you see the first time you start up an ASP.NET app. After researching, I'm finding that the Application_End event is firing shortly after the application starts, apparently killing the sessions, static values, etc.
I have the standard default web.config set up, and I am writing to the session when a page is requested. But for whatever reason, the application isn't waiting 20 minutes (or whatever the default is) before dying - sometimes it's just a minute or two, sometimes even less.
Of course, this doesn't happen locally in my dev environment - everything works as expected, with identical code and web.config values.
There is only one server, so no farm or anything like that.
I know that there are many things that cause an ASP.NET app to end - IIS restarting, app pool recycling, DLL or config file modified, reboot, etc. But I'm hoping to have a better guess when I report this to my hosting company, to help research and fix the problem. The server isn't being rebooted, and I'm not modifying any files, so that seems to leave IIS or the app pool restarting, unless I'm missing something else.
IIS restarting is in the Windows Event Viewer, so that's easy enough to find. Assuming that's not it, is there any way to determine exactly why the app keeps resetting?
Any thoughts you may have on this would be appreciated.
This is some of the reason that you may think and check for.
a command that shut-down the app.
a bug/closed loop that crash the app.
a memory limit on the application pool that shut-down the app. (this is the most possible)
a very bad iis and pool configuration on a shared server or on a virtual server. Maybe too many sites on the same iis, and at the same time a bad pool setup ?
You can check for bugs on the global.asax
void Application_Error(object sender, EventArgs e)
{
}
by log all of them and check them out.
You can check the pool setup if you have access on the iis, or ask from the administrator to check it for you and remove the memory restart limits.
Scenario: I've an n-Tier enterprise ASP.NET application deployed using Web Deployment Projects. All tiers produce independent assemblies that is consumed by the ASP.NET application.
Problem: When I run the app. for the first time after deployment it takes lot of time to load dependent assemblies in memory. But once loaded its lighting fast app. In case if there are no users accessing the app, IIS unloads the assemblies from the memory and when a user tried to access the app on a later instance it goes on loading all the assemblies once again taking the same amount of time to load as it takes to do so for the first time.
I'm looking for a solution that enables me to keep my assemblies loaded into memory persistently overriding the volatile nature of assemblies towards memory residency.
Or any other solution that lets my users happily use the app resolving the mentioned problem.
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.
One of the advantages of ASP .net is the posibility to create static (shared) instances of objects.
To avoid the necessity of an external process you can create an static timer in (per example) global.asax which calls for a page on the domain with a simple WebRequest. On this way the site keeps alive himself until a manual reset of the pool is done.
I wrote a little C# console application that keeps my 4 sites alive every 10 mins via windows task scheduler. Life is once again good. We do not run the app from 2-5am just so the serves can do any cleanups of memory, if it even matters. for our sites there is rarely anyone on at those hours anyway.
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?.
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!
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!
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.
If your pages are "updatable," they must be compiled before use. That means, yes, on first request the assemblies are loaded, compiled, and made ready for accessing. Whenever these files are changed (even some virus software can trigger this by changing the modified date of the files!), the appdomain gets recycled.
You can configure your web application to not be updatable. Everything gets compiled into DLLs, and you won't see any .ASPX or .CS files in the virtual directory. It makes your code harder to update (need to put some additional text on your webpage? Recompile time!), but it increases the availability of your web app.
However, this still won't prevent your web app from being recycled if any of the files are altered. For example, if you edit web.config, your appdomain will recycle even if its compiled.