We help IT Professionals succeed at work.

ASP.NET Session Timeout due to worker process recycling?

Our application has one page that users may fill out over an hour or more. They may start to fill it out, get interrupted and then finish the form and submit it later in the day. Because of that, the application code sets the session timeout for that page only to 8 hours. I've tested this and it seems to work fine. For example, I entered some data on the page and waited 3 hours before submitting it. The data was submitted just fine and I was still logged in to the application.

However, some of our users (customers - so we don't get all the details), occasionally report getting logged out on this page. I've looked at our IIS 6.0 settings and Recycle Worker Processes is set to 1740 minutes (29 hours) while Idle Timeout is set to Shutdown Worker Processes after being idle for 20 minutes.  During the day, it is extremely unlikely that no one is using the application for 20 minutes to cause that to run. As I mentioned above, I tested this last night when there probably wasn't anyone else on the site and my session stayed alive.

Here are my questions:
1. Even though my session timeout is set to 8 hours, can session memory get "used up" so that IIS or the application someone terminate those sessions prior to 8 hours?
2. If the recycle worker processes limit occurs in the middle of the day and a user is away from their computer for too long, would that terminate their session?
3. Instead of the 1740 minutes setting to recycle worker processes, would it be better to schedule this once per day at night when there is very little traffic?

Thanks in advance.
Comment
Watch Question

This may have nothing to do with your time out settings,  is the session tied to the ip address of the client?
Your customer may be behind a reverse proxy and getting switched to another ip address and then getting the behavior that they are no longer logged in.  
Here's an article that discusses session state in depth
http://msdn.microsoft.com/en-us/magazine/cc163730.aspx

Author

Commented:
Thank you mwochnick. It's my assumption that the loss of session is probably due to the user losing their internet connection temporarily. The application is just using the default (In Proc) model. I don't know what is used by the client to detemine the session id that is sent to the server.

Of course, even if the problem is the user's internet connection, we plan to modify this page in the future to save their work temporarily to the database so they can pick up where they left off if they have to log back in.
Just a point of clarification - in web based applications the session id is generated on the server side.  In a fat client base the session id could be generated on the client.  So in your case, based on your description it appears to be a web based app so in theory you could turn off any linking of session id to ip address but with a reduction in security

If your users are corporate users you could have them configure their proxy servers to have "sticky" sessions and elimiinate the problem for them.  If they are retail consumers then this would not work.  

Overall having an autosave feature will improve the usability and is a good option.

Explore More ContentExplore courses, solutions, and other research materials related to this topic.