What is killing my users' Asp.net session? - asp.net

We are having an intermittent problem with some users losing session. Our session settings in the web.config are as follows:
<sessionState mode="InProc" timeout="1440"/>
...which should be 24 hours (a value deliberately set over the top during testing).
Are there any other settings (maybe in IIS7) that I need to be aware of? Or are there any resources that will list the things that could kill a user's session?
Let me know if you need more information.
Thanks!
Dave

Changing the web.config file, or any of the dlls will cause the session to be destroyed, as will the recycling of app pools (this is usually set to a timeout of 20 mins of inactivity, but will also occur under certain exception conditions and possibly memory conditions)

Check Application Pool settings. There are several things there that can interfere with this:
Process recycling settings;
Several processes (then each would be keeping its own session stash);
Changing web.config or other web related files recycles the process immediately.

Anything that recycles the application pool will kill InProc session state.
Check the properties on the application pool by default there are several settings which may cause the pool to recycle in less then 24 hours.
Typically when testing there is little activity on the site and you fall foul of the pool idle timeout.

Thanks for all the replies, it seems it was because the App Pool was set to recycle at 3am and some of the users were just leaving themselves logged in over night and then just carrying on in the morning! We've added better session timeout handling now.
Thanks again!

Related

Is there a way to Make sure all active sessions in App pool are closed before recycling

I need to recycle a IIS application pool for once a week and before recycling need to make sure all active sessions in App pool are closed.
Is there a way? using .net.
The IIS recycling is usually "overlapped", meaning that requests aren't cut off: running requests are allowed to continue, while new requests are served by the new pool-instance. See here.
But this doesn't help you for sessions (which span multiple requests). An InProc Session will be abandoned by a recycle. You could however store the session-state out-of-process, with StateServer or SqlServer, so it is safe from recycles. See here.
How might that be possible? A session can take many minutes to be shut down. So it is impractical to wait for them.
I think you are asking the wrong question. You should ask "Can I prevent all sessions being destroyed on a recycle?". Answer: Yes. Use StateServer mode.

Session time out setting in ASP.Net

I have set session time out to 9 hours in web.config file something like this:
“<sessionState mode="InProc" timeout="540" />
But often users complain that they are facing time out in less than 9 hours of inactivity and the time interval after they are timed out also varies.
I was wondering if session time out is dependent on any of the below settings in IIS:
Session time setting
Idle- time out setting for Application pool
Recycling setting.
Please advise.
Also, how do I check session time out setting in IIS 7.0?
The session will be lost when the ApplicationPool recycles. That's one of the IIS settings that you mentioned. To set only the timeout in the web.config will not be enough. You need to adjust the setting in IIS.
Here is a link I found while I was looking into the same problem.
Also, this question was very useful: Losing Session State
If you are using Forms authentication you should make sure your FormAuthentication Cookie is set to expire at the same time as your Session.
If not make sure your IIS is not getting recycled. ( put a logger in your Global.asax to verify the application end events compared to your users complaints.)
It is not enough to set session time out in your web config. If the server on which your site is hosted is having less time out value set in IIS setting, your session is time out according to the server session time out value.
also if you are deleting any folder from the server directory, this can also cause your AppPool to recycle unexpectedly.
so please check the server session time out value and if it less then ask your hosting to increase it as per your requirement.

Asp.net Application State expiration

I suppose that application state and session state are two different things.
If I can set expiration time to session state, can I do same to an application state in my web.config ?
I just want to prevent my application from rebuilding after 5 minutes.
I don't know exactly what happens. When accessing the website for the first time, the site takes 10 seconds to appear. If I return to the site before 5 minutes, the site appears immediately. If there are more than 5 minutes of inactivity, when I access the site again, the site takes 10 seconds. I guess it was the application state Who expired ?
The easiest way I know of to keep your site alive is to make sure traffic is always coming through. If you have access to a scheduled job runner, have it ping a dummy aspx page every minute or two - this way, your app should run indefinitely.
If not, there are techniques to cheat the system. You can have a cache item built, and upon expiration of that cache item, create another cache item. This will perpetually keep running code every X minutes, which will keep the app alive. The problem with this is that if the app ever does die (server reboot, IIS restart, etc.), the app will be dead until someone makes a real request, at which point it will stay alive indefinitely again.
This technique is sometimes used to simulate a task scheduler in ASP.NET. Just keep in mind that it's not perfect.
EDIT: For clarification, you wouldn't just create a new cache item, you'd actually make a request to a page which would then in turn create the cache item. This ensures that another request is made through IIS, which in turn runs the full lifecycle, keeping the app alive.
Even if you do set your session timeout high, there's no guarantee that it will hold. I've dealt with hosting companies who will recycle your application pool after just a couple minutes of inactivity, killing any sessions you may have open. They don't care that you may have sessions open - they are just trying to squeeze every CPU cycle they can out of their servers. So if you're on shared hosting, you may want to keep that in mind - you may not be able to control how often they kill your app.
Application State starts when the first session is created, and is automatically ended after the last session expires. As long as you have continued access to the website, the application will remain active.
I don't know what you mean by having application "rebuild". Changing any file related (i.e. file with compilable code) will cause the application to either recompile (if you have a web directory) or reload (if you have a web application). This action will always end all sessions and end the application.
Not sure it is still actual.
The problem doesn't linked with SessionState or ApplicationState.
To avoid slow reaction of your web-site you have to activate AlwaysRunning mode of your IIS
To do that add to your web.config the next
<applicationPools>
<add name="MyAppWorkerProcess" startMode="AlwaysRunning" />
</applicationPools>
You can configure your session state in your configuration file for preventing this expiration.
For example:
<sessionState
mode="SQLServer"
sqlConnectionString="data source=127.0.0.1;user id=<username>;password=<strongpassword>"
cookieless="false"
timeout="20"
/>

How to force a 20 minute time-out for sessions?

I'm very confused when it comes to what actually decides the session time-out.
The web app needs to allow for a 20 minute "idle time" before logging (or throwing) users out. I've tried different setting on both sessionState and Recycle worker processes in IIS. The time-out remains too short and, as far as my quit-n-dirty, primitive tests have shown, a bit random.
I read somewhere that the default time-out is 20 minutes, but in my app it appears to be closer to five. Are there any easy ways to change this? The app is running .NET 3.5 on IIS 6.
EDIT:
I just realized that the Entity Framework might have something to do with the problem, as the user content is held as a context in the entity framework. Is there any time limit for how long an entity is held?
The user will be logged out based on your Authentication settings in the web.config.
The Session timout will be set in your session tag in the web.config.
If they are different then you will see "interesting" results.
http://msdn.microsoft.com/en-us/library/ms972429.aspx
If you look in the web.config you can write some thing like this
<configuration>
<sessionstate timeout="20" />
</configuration>
and there you can set you timeout..
Use the sessionstate timeout. You do not want to use Recycle Worker, as this will recycle all sessions associated with that worker, every N minutes. It's a good idea to set Recycle Worker to a very high value if you are using the session variable.

ASP.NET Application Restarts Too Much

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.

Resources