I have an ASP.net application where Users aren't able to successfully complete certain actions, for reasons, I'm assuming, can only be related to losing their session (which is where I maintain their current user information, and how determine whether they are logged in)
I'm at a loss as to why they would lose their session, so my first question is:
What (in general) would cause a user to lose their session in ASP.net?
and since I don't know when a user loses their session and can't reproduce it myself:
How can I track when I user loses their session
Below is my sessionState config for reference
<sessionState
mode="InProc"
cookieless="false"
cookieName="My.Site.Com"
timeout="480"/>
A number of things can cause session state to mysteriously disappear.
Your sessionState timeout has expired
You update your web.config or other file type that causes your AppDomain to recycle
Your AppPool in IIS recycles
You update your site with a lot of files, and ASP.NET proactively destroys your AppDomain to recompile and preserve memory.
-
If you are using IIS 7 or 7.5, here are a few things to look for:
By default, IIS sets AppPools to turn themselves off after a period of inactivity.
By default, IIS sets AppPools to recycle every 1740 minutes (obviously depending on your root configuration, but that's the default)
In IIS, check out the "Advanced Settings" of your AppPool. In there is a property called "Idle Time-out". Set that to zero or to a higher number than the default (20).
In IIS, check the "Recycling" settings of your AppPool. Here you can enable or disable your AppPool from recycling. The 2nd page of the wizard is a way to log to the Event Log each type of AppPool shut down.
If you are using IIS 6, the same settings apply (for the most part but with different ways of getting to them), however getting them to log the recycles is more of a pain. Here is a link to a way to get IIS 6 to log AppPool recycle events:
http://web.archive.org/web/20100803114054/http://surrealization.com/sample-code/getnotifiedwhenapppoolrecycles/
-
If you are updating files on your web app, you should expect all session to be lost. That's just the nature of the beast. However, you might not expect it to happen multiple times. If you update 15 or more files (aspx, dll, etc), there is a likelyhood that you will have multiple restarts over a period of time as these pages are recompiled by users accessing the site. See these two links:
http://support.microsoft.com/kb/319947
http://msdn.microsoft.com/en-us/library/system.web.configuration.compilationsection.numrecompilesbeforeapprestart.aspx
Setting the numCompilesBeforeAppRestart to a higher number (or manually bouncing your AppPool) will eliminate this issue.
-
You can always handle Application_SessionStart and Application_SessionEnd to be notified when a session is created or ended. The HttpSessionState class also has an IsNewSession property you can check on any page request to determine if a new session is created for the active user.
-
Finally, if it's possible in your circumstance, I have used the SQL Server session mode with good success. It's not recommended if you are storing a large amount of data in it (every request loads and saves the full amount of data from SQL Server) and it can be a pain if you are putting custom objects in it (as they have to be serializable), but it has helped me in a shared hosting scenario where I couldn't configure my AppPool to not recycle couple hours. In my case, I stored limited information and it had no adverse performance effect. Add to this the fact that an existing user will reuse their SessionID by default and my users never noticed the fact that their in-memory Session was dropped by an AppPool recycle because all their state was stored in SQL Server.
I was having a situation in ASP.NET 4.0 where my session would be reset on every page request (and my SESSION_START code would run on each page request). This didn't happen to every user for every session, but it usually happened, and when it did, it would happen on each page request.
My web.config sessionState tag had the same setting as the one mentioned above.
cookieless="false"
When I changed it to the following...
cookieless="UseCookies"
... the problem seemed to go away. Apparently true|false were old choices from ASP.NET 1. Starting in ASP.Net 2.0, the enumerated choices started being available. I guess these options were deprecated. The "false" value has never presented a problem in the past - I've only noticed in on ASP.NET 4.0. I don't know if something has changed in 4.0 that no longer supports it correctly.
Also, I just found this out not long ago. Since the problem was intermittent before, I suppose I could still encounter it, but so far it's working with this new setting.
In my case setting AppPool->AdvancedSettings->Maximum Worker Proccesses to 1 helped.
Your session is lost becoz....
JUST MAKE SURE THERE ARE NO RUNTIME ERRORS, ANY FATAL EXCEPTION WOULD
KILL THE SESSION!
In Microsoft stack, Visual Studio - put Ctrl + Alt + E - All Exceptions ON, then run the code in Debugging mode. Any Fatal ones are THE reason for session loss..
You could add some logging to the Global.asax in Session_Start and Application_Start to track what's going on with the user's Session and the Application as a whole.
Also, watch out of you're running in Web Farm mode (multiple IIS threads defined in the application pool) or load balancing because the user can end up hitting a different server that does not have the same memory. If this is the case, you can switch the Session mode to SQL Server.
I was only losing the session which was not a string or integer but a datarow.
Putting the data in a serializable object and saving that into the session worked for me.
Had a problem on IIS 8 when retrieving Content via Ajax. The issue was that MaximumWorkerProcesses was set to 2 and Javascript opened 17 concurrent requests. That was more than the AppPool could handle and a new pool (without auth-data) was opened.
Solution was to Change MaximumWorkerProcesses to 0 in IIS -> Server -> Application Pools -> [myPool] -> Advanced Settings -> Process Model -> MaximumWorkerProcesses.
Dont know is it related to your problem or not BUT Windows 2008 Server R2 or SP2 has changed its IIS settings, which leads to issue in session persistence. By default, it manages separate session variable for HTTP and HTTPS. When variables are set in HTTPS, these will be available only on HTTPS pages whenever switched.
To solve the issue, there is IIS setting. In IIS Manager, open up the ASP properties, expand Session Properties, and change
New ID On Secure Connection to False.
I had same problem by losing sessions. every time , every page reload, my sessions clear and by new reload any page, my sessions returned by valid value...
i fixed it by change MaximumWorkerProcesses from 0 to 1 in iis
I was struggling with this issue for 14 days.
Here's what helped me:
Check your recycling options in App Pool > Advanced settings. Turn off all of the options so it won't recycle on its own.
Check your web.config file for the executionTimeout property under httpRuntime and increase its value.
Check your web.config file for the timeout property under sessionState and increase its value (I set it to 300 minutes).
Go to the server's event log and check the Application log for unhandled exceptions that may cause the worker process to crash. Fix them in your code or use try and catch to eliminate this crash.
Try changing the value of your maximum worker process from 0 to 1 or the other way around, this may also solve this issue.
In my case, session state was loosing due to Load Balancer. Session was storing in one server and Load balancer was redirecting next call to another server where session state was missing.
Related
Site hosted via IIS 7.0
I would like to set my session time-out to 9 hours in my ASP.NET application.
This has been set at web.config
<sessionState timeout="540"></sessionState>
But, as I understand, if the timeout is set as 20 minutes inside the IIS where the website is hosted, setting an extended session state will be of no use.
Firstly, I would like to confirm whether this assumption is right.
The problem is that I do not have access to the IIS of my shared hosted web server.
Now, after some research, I came up with another solution in code project. This sounds like a wonderful idea. The idea is to insert an iframe to master page. The iframe will contain another page with meta refresh less than 20 minutes.
Response.AddHeader("Refresh", "20");
This idea seemed good for me. But the article is 7 years old. Plus at comments section a user complaints that this won't work if the page is minimized and I am worried that the same happens when my pages tab is not active.
I would like to know these things
Whether the refresh method will work for my scenario , even if the page is minimized?
Are there any other methods that could increase session time out that overrides IIS timeout setting?
Also I read some questions in Stack Overflow where the answers state that the IIS session timeout is for clasic ASP pages. Then why is not my extended timeout not firing?
Firstly, I would like to confirm whether this assumption is right.
Yes, this assumption is absolutely right in case you are using in-memory session state mode. In this case the session is stored in memory and since IIS could tear down the AppDomain under different circumstances (period of inactivity, CPU/memory tresholds are reached, ...) the session data will be lost. You could use an out-of-process session state mode. Either StateServer or SQLServer. In the first case the session is stored in the memory of a special dedicated machine running the aspstate Windows service and in the second case it is a dedicated SQL Server. The SQL Server is the most robust but obviously the slowest.
1) Whether the refresh method will work for my scenario , even if the page is minimized?
The hidden iframe still works to maintain the session alive but as I said previously there might be some conditions when IIS unloads the application anyway (CPU/memory tresholds are reached => you could configure this in IIS as well).
2) Are there any other methods that could increase session time out that overrides IIS timeout setting?
The previous method doesn't increase the session timeout. It simply maintains the session alive by sending HTTP requests to the server at regular intervals to prevent IIS from bringing the AppDomain down.
3) Also I read some questions in Stack Overflow where the answers state
that the IIS session timeout is for clasic ASP pages. Then why is not
my extended timeout not firing?
There is no such thing as IIS session timeout. The session is an ASP.NET artifact. IIS is a web server that doesn't know anything about sessions.
Personally I don't use sessions in my applications. I simply disable them:
<sessionState mode="Off"></sessionState>
and use standard HTTP artifacts such as cookies, query string parameters, ... to maintain state. I prefer to persist information in my backend and retrieving it later using unique ids instead of relying on sessions.
Hey I have the following line in my web.config
<sessionState mode="InProc" timeout="45"/>
Which I thought would keep sessions intact for 45 mins
But I have seen the case where if a user is inactive for lets say 15 mins the sessions times out.
How can I stop this ?
Edit : Just noticed I have the following line in the master page
meta http-equiv="Refresh" content="1800;URL=http://www.virtualacademy.ie/login.aspx">
Maybe this is causing the issue, what is the above line doing i.e the number 1800
Be sure to check your IIS configuration because the application pool that your site is hosted on also has its own timeout value which will override your own .config.
To increase it,
Open IIS
Select Application Pools on the left side
Select the Application Pool used by your site
Choose advanced settings
Under Process Model categtory increase the 'Idle Time-out' value to the desired length.
Hope this helps.
(If you do not have a dedicated server / access to IIS with your hosting provider you will have to contact them to see if they can increase it for you)
If the user closes their browser or clears cookies, or if the AppDomain on the server is recycled, the session state will be lost.
Have you checked logs to see if the app is recycling?
AppDomain recycles are a very common problem for this if the sessionState is InProc. It is very much advised to use a StateServer or SQLServer for production systems instead. See Session-State Modes for documentation on how to use each, and the pros and cons of the three different types.
Personally, we use SQL Server if we must for web server farms--slower but can be shared. We use State Server if the site will only be hosted on a single web server--state survives AppDomain restarts, but not entire server restarts.
Also, in the past we have used an AJAX post in the background while the user is watching long running videos or performing long client-side tasks, so that the session timeout gets reset every few minutes. Nothing special about this code--just have a little JavaScript hit every few minutes some ASPX page that returns nothing.
Are you using Forms Authentication? It has its own timeout setting that when expires will redirect the user to your login page even if their session is still valid.
I have an ASP.net website where I am facing a session timeout issue. In web.config I have set session timeout to 480 (8 hours as session time). But even then session does not stay that long; it goes out after a number of minutes. Why is that and how I can fix it? My site is hosted on a shared hosting server.
By default Session time in asp.net is 20 min, and we can change it by setting Web.config file.
Now in your case you are setting it to 8 hours but went out in 1 min.
Do you know that there are few point by which session can be time out?
*) When it is wrongly configured in Web.Config file.
*) We can set this time out in server (IIS) also, so if its default setting is changed.
*) When the total memory of session is higher that the assign in shared host.
*) When there are some internal error at run time in any page, then session will be lost.
*) When some one or any process is changingadding any aspx file or web.config file at runtime.
So check all these point. I am sure it will resolve your problem...
Also, have you checked the app pool recycling options?
Your hosting provider have probably set some low value in "Recycle worker processes" in IIS for your application pool. Not sure if they can change that for you but you could try to ask them.
There are many reason which cause your session timeout before the actual value configure in web.config file.
one such reason is that if you hosted your applcation and forgot to reset the app pool after deployemnt.
or
once you deploy the application for first time then its corresponding app pool may get reset dusring the first run of application.
or if your app pool may get crash in between the process..
You can diagnose this problem first check your app pool (in advanced settings- if you hosted your application in IIS) now by going to the Event Viewr and check the logs in Custom Views go to server role then find the log by clicking find button at right side pane and paste your app pool name in search box.
check for the error or warning message related to app pool.
i hope this ma help you
In the web.config file for my application, in the <sessionState>
section I have set timeout="60" (in minutes), but session state
variables in my application seem to be expiring in about 1 minutes.
Any idea what could cause this?
Yes.
Session timeouts are also specified and controlled by IIS (although there is overlap ofcourse). In IIS 6.0 you also need to check the following places in IIS manager (properties of Virtual directory):
ASP.net tab > Edit configuration > Authentication tab > Cookie timeout
ASP.net tab > Edit configuration > State management tab > Session timeout
Setting all these to the same value, fixed the issue for me.
edit: Apparently the previously listed first option, had nothing to do with it. That means, that the first of the two options is now the place for you to fix your session timeout. It's probably not your session timing out, but the authentication expiring.
Or another possibility is that the worker process is restarted, or the application is restarted. Also things to look into.
If you are storing session state "in proc" then every time the app pool recycles you can loose session (this can happen a lot on a server with low memory). You could try storing session state "out of proc" using State Server or SQL Server.
See PRB: Session Data Is Lost When You Use ASP.NET InProc Session State Mode
I have an ASP.NET WebSite which restarts in every 1-2 hours in a day so sessions and other thing are gone and users are complaning about it, because they open a page and do something for 20 minutes and when they submit it, a nice "we are sorry" page is there.
I don't do anything which restarts the application (changing the web.config, changing the files, or even other buggy things like deleting a folder in App_Data which normally shouldn't cause a restart).
Can it be related with Server's hardware? It is not much powerful.
I guess this is recycling.
App pools in IIS get recycled by default - either after a timeout, or after "n" hits.
This should be expected, and is part of the normal processing (although it can be disabled in the app-pool configuration; IIS6 | IIS7).
The fact that this breaks your app suggests that you are using a lot of things like in-memory sessions. Consider moving these to database backed implementations. Apart from withstanding both app-pool restarts and server reboots, this can allow you to scale the site to multiple servers.
Check this blog post about some possible causes for appdomain recycles. There are many possible causes.
If you are unable to fix the problem you could switch from in-process session state to eiter a session state server or to storing session state in a database. Both options are easy to set up and works quite well, but there is a performance impact (between 10-20% I think). There is a nice article here about how to setup a session state server.
Sounds like the app is being recycled or process is failing.
Check app pool settings http://msdn.microsoft.com/en-us/library/aa720473(VS.71).aspx
and event viewer.
Since you mention that your server is small, you might check to see if your worker process is consuming more memory that you have set in your processModel in machine.config. That can cause a reset.
Are you sure that the ASP.NET application actually restarts? Or do you think that it happens because of the lost Session and such?
What is your application's (and IIS') Session timeout variable? The default value of the timeout is 20 minutes, so that's why I am asking. You can set the timeout in your web.config as follows:
<system.web>
<sessionState timeout="120"/>
</system.web>
But apart from that, there are also places inside IIS itself where you can set it. In the case of IIS6 those places are:
Properties of a virtual directory > Home Directory (tab) > Configuration (button) > Options (tab) > Session timeout
Properties of a virtual directory > ASP.net (tab) > Authentication (tab) > Cookie timeout
I'm not sure whether or not both are actually needed, but I usually set both to the same value as I set it in my web.config.
Is there any indication of the cause of the restart logged in the Event Log?
Do you have any anti-virus software running on the server. A change to the web.config will cause your application to restart afaik so in some instances anti-virus software passing over the web.config might alter the attributes on the file which could be causing the reset.
Try disable any AV software or exclude the web applications directory from the AV auto scanning.