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.
Related
For an ASP.NET Website where i am making updates. What would cause user sessions to reset?
From my understanding if i make any changes to files in the app_code folder or the global.asax file it will reset everyone's session but if i made a change to .cs file (in the top directory) it wont reset everyone's session?
Would it reset the session of anyone that was on that page that i updated?
Can someone help me with my understanding, thank you.
Assuming memory-based session (as opposed to sql server based).
Well, the app pool restart will blow out session.
(so, in some cases even un-handled errors will blow out session).
Modify web config?
that will case app pool to restart (and blow out session).
Update any folder outside of app_data. Again, app pool re-start (and blows out session).
change content of bin folder - again app pool re-starts, (and blows out session).
Update code behind (.cs, or vb pages (code behind)). - again, app pool re-starts, (and blows out session). (so anything that will cause a re-compile of code).
There are probably a good many more - the above is a basic list.
You can thus consider adopting sql session based, and that will thus be far more robust, and I even re-started IIS services, and users if not doing anything just looking at their web page while logged on? They were able to continue working even after a full re-start of IIS services.
On the other hand, I now always use a asp.net web site "applcation". Thus no souce code is placed on the web server, and my compile is done with visual studio before deploying. The only big issue is that if you change to a application deployment model, the even just changing one line of code behind will force/require a full re-publish of the web site.
It looks like you are using a web site, and thus source code (code behind) is placed on the web server. Thus, IIS has the job of re-compiling such code, and thus any code change will as a general rule cause a app_pool re-start, and thus loss of session.
As noted, if you change from in-memory session to SQL server based (turn that feature on), then most if not all of your session issues will go away. Even if you not using "application deployment" and have/use code behind on the site for IIS to re-compile? Then using sql server-based session management should fix all of your session() woes.
I've deployed an ASP.NET MVC app (on runtime 4.5.2), which works in development, and also on Azure.
But when deployed to my actual production environment, which is shared hosting on IIS 8.5, I get frequent app recycles, usually every few minutes or after only two or three requests! Sometimes the app bombs so badly, I need to ask them to restart it manually because it doesn't restart automatically.
The only thing I've done which is maybe non-standard, is I've disabled session state in web.config, because I don't use session.
In Application_Error I log errors. In Application_End I log HostingEnvironment.ShutdownReason, which is always equal to HostingEnvironment, which isn't helpful, because all that means is "The hosting environment shut down the application domain."
They refuse to let me see their server logs.
My app is (I think) bug-free, and as I stated above, it works perfectly on Azure. So there is a problem somewhere between how IIS is configured, and my app behaves.
What can I do to drill down into this problem?
I initialize static state of my web applications in Applications_Start method (Global.asax). At that time I write a message to log. Suddenly I've realized that this method was called every 10 minutes.
Is it corrected behavior? I expected ASP.NET to keep its applications at least for several hours.
Your expectation is incorrect. This is set in the application pool setting in IIS configuration. I think the default is 20 minutes. This can be changed to 0 if the application pool should not be recycled.
This is not typical. Something is causing it to restart and it should not be doing so this frequently. Check out How to find out why an ASP.NET web application is being restarted question to see how you can log details on why it restarted.
Since you are writing out log files, maybe you are writing them to a location that is be monitored for recompilation, which will cause a appdomain restart. Check out the post What causes an application pool in IIS to recycle?
Check out this article on iis.net to see the default for recycleing. It is 29 hours, so unless this setting has been changed for you, something else is causing it, not the automatic recycle.
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.
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?