We are using an ASP.NET web application, IIS 7.5 using Windows Authentication.
Anonymous, ASP.NET Impersonation, and Forms Authentication are all turned off.
Session timeout is set in the application at 120
< sessionState timeout="120" />
Application Pool idle timeout is set to 180, recycling is done each morning at 3:00 AM (lowest usage time). This does not happen in relation to updating files.
The users are logging in via Chrome or IE, and it works fine, until it doesn't.
User complain they are suddenly asked to log off after a few minutes of inactivity... sometimes. This does not happen all the time.
I have been looking at logs, events, etc and cannot find anything to let us know why this is happening.
Does anyone have any idea why this would be happening?
Make sure the idle timeout isn't set on the app pool in IIS. The default for that setting is 20 minutes (which leads to confusion over whether the timeout was triggered by session timeout or idle timeout) and in most cases can be safely set to 0, which turns it off.
To check the idle timeout in IIS, go to Advanced Settings for the app pool.
The idle timeout is a sliding window based on activity for the app, so requests from any client will reset the window. If your app is lightly used, you'll hit the timeout frequently, causing your app pool to recycle. The impact to users is that any sessions that had been active will be lost, and users walking up to your app after it has been idle will have to wait for it to run all of its start up processes.
https://technet.microsoft.com/en-us/library/cc771956(v=ws.10).aspx
Related
Setting my forms authentication timeout and sessionState timeout from my config never seem to have the desired effect. I always have to set the sessionstate timeout on the website on the server and it also seems like I need to set the application pool idle timeout as well.
What is the point of the config setting if the server can just override it?
What are the priority of the settings, strictly in terms of authentication and the time to keep a user logged in? I have not done extensive testing on this but it feels like if any of the 4 settings are out of sync, the users don't get timed out predictably.
The main thing is that they aren't related at all.
Forms authentication timeout won't have anything to do with session timeout. Forms authentication timeouts may or may not slide and only store the authentication cookie. Even if they are set to slide a user still has to interact with the server after the halfway point in the timeout for it to slide, else it doesn't.
Session timeout is just there to store data for X amount of time if needed and the timeout will slide.
The application pool is there to keep everything running smoothly. Application pools need to recycle every so often and that can be disruptive, but it's the health of the app and the server they are worried in. Of course, if you aren't using a state server or storing session in database the session can end up killed off as well.
Couple things that help in this scenario:
Use session wisely as it's a pig for resources, and always have a means to check for nulls and recreate the needed objects/values if it is null.
Create a machinekey for your app. This will make sure the way that the app encrypts data doesn't change with each app recycle. If a recycle occurs it could have an effect on logged in users because the encryption of the ticket may not match. A nice side effect of creating an explicit machinekey can also help you use a webgarden if you want, but only if you a state server or store session in db since in memory session can't be shared among processes.
So they aren't inter-related but can effect each other. There is also no way in hell I would want an application to have it's own settings that would over-ride an app pool setting since a well set app pool keeps the site and server healthy and running well and that's the main reason it trumps all.
I have an ASP.NET 4.0 web app running in a load balanced cluster with 3 nodes. The website is expected to run continuously for more than a day without much user activity. The website keeps refreshing its contents for every 5 minutes.
The website is configured with high values for session timeout and execution timeout. The Application Pool has been configured not to recycle automatically. The session mode being used is SQLServer. We have also specified machine key in the web.config to avoid session errors.
However, we have been still noticing the session to timeout during night. The web server Event Viewer doesn't show any errors related to Application Pool recycle. When we get error in the website, the website redirects to the WSSO login page (on refreshing) indicating that session has timed out. WSSO timeout has been configured to 16 hours. And in this case, the website refreshes every 5 minutes.
Could anyone please advice what could be the cause for the timeout.
Thanks,
Arvind
I setup ASP.NET Auto-Start on my Windows Azure Web Role (I use ASP.NET 4.5 and IIS 8 on Windows Server 2012). I basically followed those instructions.
I am setting startMode="AlwaysRunning" on the application pool and preloadEnabled="true" on the website through the OnStart method of the webrole.
I used remote access and verified that those two properties are correctly set (through IIS Manager, as well as checking the applicationHost.config file).
I also added this to the web.config file:
<applicationInitialization skipManagedModules="true">
<add initializationPage="/" />
</applicationInitialization>
This page says the Idle Timeout should be disabled when auto-start is enabled. Yet, I can see from my log that it is not, the application pool gets restarted after some inactivity. I can also see that in the event log (several times over 6 hours):
A worker process with process id of '772' serving application pool 'cf9d3284-6454-4bbf-8a8e-efd73df4ed83' was shutdown due to inactivity. Application Pool timeout configuration was set to 20 minutes. A new worker process will be started when needed.
The strange thing is that it seems a new application pool is started immediately after this is logged, even if there is no request to the website. So if I don't get a single request in one hour, the application pool is recycled and restarted 3 times (I confirmed this from the logs). Is my configuration incorrect or am I missing something?
Setting the Start Mode to Always Running alone didn't work for me either but setting the Idle Timeout to 0 in the application pool's Advances settings did.
(http://developers.de/blogs/damir_dobric/archive/2009/10/11/iis-7-5-and-always-running-web-applications.aspx)
i have struggled a lot in this issue. I did everything i could to keep my services alive in IIS but eventually got tired and had to take different approach. I created a windows service just to keep those app pool alive. One approach you can try is go to IIS config file and verify that you can see the configuration you made is reflected in that config file.
Refer to the link on top. But your configuration will be reset on app pool restart whatever time you set it to go to sleep. You might need to comeup with some approach.
I've made one Asp.net MVC website, and I'm very confused between the different timeout settings.
What is the difference between:
SessionState Timeout in web.config:
Application pool timeout
Asp.Net Session timeout property
Which one should I set if I want to have a timout of (say) 6 hours? All of them? Only some?
The application pool timeout is the length of time the site has to be idle for before the application pool will shut down the worker process to release resources. The downside is that when the next visitor comes to the website it takes a long time to restart things so that first request after a shutdown will be quite slow.
IIS7 Application Pool Idle Time-out Settings
The session timeout refers to the session id that a user gets on first request to the site, and when that expires.
I think the ASP one that you've included the screenshot of is for classic ASP, not ASP.NET.
So to increase the session timeout you would use the one in the config file.
There's also a Session state section when you click on the website in IIS that you could possibly use either and there's a timeout at the bottom of the page for it.
But if the value for the application pool timeout is shorter, then your session setting will be irrelevant as the worker process will shut down before the session expires. So you should also change your application pool settings.
Session Time out in IIS 7
Already someone has raised this question in this forum regarding session timeout. Would appreciate if someone can clarify this again.
I have an asp.net 2.0 application which times out after say 15-20 minutes if user didnt do any activity and presses a button on the page(he is redirected to sessionExpired.aspx page). I have set the session timeout to 60 minutes in my web.config file but still somehow the user is timed out.
I have another question related to this regarding the Session Timeout Precedence. Does IIS session timeout take priority over ASP.NET session timeout. Say if IIS session timeout is set to 20 minutes and ASP.NET session timeout is 60 minutes, does ASP.NET override IIS session timeout.
IIS takes precedence, but they deal with slightly different scenarios.
In the case of IIS, the default 20 minutes time-out for the application pool is referring to incoming requests. If your application doesn't receive any requests at all for 20 minutes then the application pool is put to sleep to save resources. When this happens all the sessions in your application are gone.
The ASP.NET session time-out deals with per-session requests. Your site could be quite busy, but if one user (i.e. session) is not active for 20 minutes only that session is discarded.
So yes, to make sure the session stays alive for 60 minutes you have to change the time-out settings for the IIS application pool as well as web.config.
Another way of approaching this problem is to periodically send a small AJAX "ping" (i.e. a page request with a random ID to prevent browser caching) back to the server. This way, as long as the user doesn't close the browser, the session will be preserved.