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.
Related
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
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'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
On my website, members can write articles to share info with others in their community. I get random reports that the submit fails, and it appears it is because of session timeout.
If I create a small ajax script to "ping" an action on my ASP.NET MVC controller every few minutes, would that reset the session timeout? Or is there a better way?
An ajax ping is what I do in my Java EE MVC web application to keep the session alive, and it works fine. I don't see why it should not work for a ASP.NET application as well.
I am not sure if there is a better way, though.
Yes, that will do the job.
Independently of the technologies, every time an http request reaches the http server, the session "last access time" is updated to the date the communication has been initiated by the client.
If you ping to the server with a delay less than the session timeout you will preserve the session for ever!
Note: you don't need to ping every minutes if your session time out is 30 minutes. It will overload the network for absolutely nothing. I would recommend the session to ping every 25 minutes for such configuration.
HIH
M.
We have a ASP.net form [.NET 3.5 on IIS 6] that loads controls dynamically. We are able to retain the values in the viewstate as long as the postback happens within 20 minutes. The database also gets updated properly. Everything works as expected.
However, If it takes more than 20 minutes for a user to fill out the form, the controls no longer retain their values during postbacks. The session values are intact, the user authentication is also intact. We tried several things
1) Added machine keys to web.config files - we have 2 web servers load balanced by Windows load balancer
2) We confirmed that the user are routed to the same server – because the sessions are sticky
3) Increased the session timeout to 60 minutes in IIS 6.0
4) Increased the Idle timeout for connection pool to 60 minutes
5) Changed Form authentication ticket timeout to 60 minutes
Any help would be appreciated.
-Thanks
20 minutes is the default timeout for application pool recycling. Run IIS Manager on the server, go into the Application Pool properties, and unclick 'Recycle worker processes (in minutes)', or set it to 60.
"sticky" sessions do not mean "always go to same server". It is just a suggestion. Granted, a strong one, but still just a suggestion. The load balancer works by keeping an in memory cache of clients and their destination server. This memory is limited and is garbage collected on a regular basis. Meaning, you might very well be bouncing between servers based on the amount of time between requests.
If you are using in memory session data with load balanced machines, then you have to either 1. stop using session or change the backing store to be a session state server or sql server. This is the only way to be sure that the session data is actually available across all target servers.
How did you determine that the session and user values were still intact? Are you just guessing like you are about which server they are going to?
To completely eliminate load balancing as a culprit, turn off all but one of the machines.
Problem can be in <sessionPageState historySize="9" /> configuration. It control's how many "postback results" are stored in Session. Each postback records it's ViewState to the end of the Queue in Session["__VIEWSTATEQUEUE"].