locked
Session State lost after Recycle of app pool --- some times RRS feed

  • Question

  • User-1544434412 posted

    I have an application that was built as a "web application project" through visual studio.   It is built in vb.net and is currently running using the 4.5 framework.   Session management is running 'in proc'.  This application runs on hundreds of different clients site, hundreds of different servers (not in a web farm, all individual clients).   I recently got a call from one of them stating that they were randomly getting errors.   In looking at our error log, it appears as though the session data is getting lost.    From what I can tell, it is around the time of a IIS App Pool recycle.  This is the only client who is reporting this.   So, why would only one client be reporting issues, and not all of them?   Considering that the default recycle time is every 29 hours.   When I do some testing, I am able to reproduce what this one client is experiencing.   I time my IIS App pool recycle every 5 minutes.  After 6 minutes my session is gone.   Kind of to be expected based off reading and what others are stating.  At this point, I must logout/login/close all browser sessions/restart my session.

    I started digging and doing some testing and I have another application that we have that was built as a "Web Site" through visual studio.  Happens to be a c# application also on 4.5 frame work (if this matters).  When I do some testing, I time my IIS App pool recycle every 5 minutes, After 6 minutes... MY SESSION IS NOT LOST, everything works fine.  No need to log back in.   I have pointed this application to the same exact app pool that I used in the 'web application' above.

    So, with all that said, I have questions that I can't seem to find the answer to anywhere.

    1. Why would only 1 customer be reporting this issue, and not all hundreds?

    2. What is different about a "Web Site Project" and a "Web application project" that would make the session life span act differently?

    3. How can I 'recover' the lost session data while still using IN-PROC management after a recycle.

    4. What other ideas of things/settings to look at?

    5. In today's day in age, do we really need to be recycling the app pool every 29 hours?   Isn't the garbage collectors and the other .net magic suppose to help in recovery of any 'memory leaks'?  Thus virtually eliminating the need of a recycle of app pool this frequently?

    Much appreciated.

    Monday, February 20, 2017 1:14 AM

All replies

  • User-271186128 posted

    Hi pebkac1205,

    As far as in know, if we are using InProc mode, data loss can occur if different requests for the same session are served by different worker processes. So, I suggest you could use Session SQLServer model or StateServer mode. More details about that, see: https://msdn.microsoft.com/en-us/library/ms178586.aspx

    Best regards,
    Dillion

    Monday, February 20, 2017 2:24 AM
  • User-1544434412 posted

    Thank you for the reply.   At this point we can't transition to using SQL/State server service since some of our current objects are 'old' and can't be serialized with out some re-work, or building a custom state provider.  It is on our list of code changes, but really not a high priority yet.   I am trying to figure out what makes things respond different in the different scenarios I outlined.   Maybe its a settings I can change, or something; Something that makes a 'website' act different then a 'web application'.

    Thanks.

    Monday, February 20, 2017 1:47 PM
  • User475983607 posted

    pebkac1205

    2. What is different about a "Web Site Project" and a "Web application project" that would make the session life span act differently?

    As far as I know, both web apps and web sites lose Session when the app pool is cycled.  This is because Session is stored in server memory and cycling the application resets the memory which has nothing to do with the application  You might want to verify your test scenario is accurate.  At least, I have never experienced a web site retaining Session after a cycle.

    Secondly, Session may or may not be related to login.  These days Session and authentication are two different frameworks.  If you are using a modern cookie base authentication (forms authentication) then cycling the app pool will not affect the user as long as the application is configured to use a consistent machine key.  The user's Session will be lost though.  

    5. In today's day in age, do we really need to be recycling the app pool every 29 hours?   Isn't the garbage collectors and the other .net magic suppose to help in recovery of any 'memory leaks'?  Thus virtually eliminating the need of a recycle of app pool this frequently?

    Garbage collection does not fix memory leaks.  There are plenty of opportunities to write a leaking application.

    Monday, February 20, 2017 3:21 PM
  • User753101303 posted

    Hi,

    #1: I wouldn't care about that (for example it's usual to have a "it works fine on localhost but fails once deployed"). What matters is what happens for the user for which you have this problem. My first thought is that you should be able to get a reason about why the application pool is recycled. It could be also that this pool is shared with other applications that have an isssue.

    #2 : Afaik nothing. This is an IIS feature and is irrelevant to the kind of project itself (ah, for a web site project you have a compilation step which might perhaps trigger that, are you using a web site project ?).

    #3 : Depends on how you are using it. For example if used as a "cache" you can reaload the value from the db if lost. If the value doesn't exists anywhere else you have no way to recover the lost data (unless you persist it yourself as a backup somewhere but you would have the same problem than using the SQL Provider which you don't want to do for now).

    #4: try perhaps https://blogs.msdn.microsoft.com/johan/2007/05/16/common-reasons-why-your-application-pool-may-unexpectedly-recycle/ but I would look at http://webmasters.stackexchange.com/questions/17630/which-event-log-file-does-iis-7-app-pool-log-to first to enable and trace recycling events and find which reason is reported

    #5: it's a kind of safety net. Feel free maybe to disable that for now but if your user is running into this frequently I dbout he have this issue only because of this reason

    Monday, February 20, 2017 3:37 PM
  • User-1544434412 posted

    #2, the one that does NOT have issues after the Recycle of the app pool is a "Web Site" project in visual studio.  ....... The one that does fail after a recycle is a "Web Application" project.

    #4, I have reached out to the customer to enable more logging for app pool recycle.   They want to schedule it, so, for this I am kind of in a wait game :(   I will review the other site for more information a little later, thank you.

    Monday, February 20, 2017 5:44 PM
  • User475983607 posted

    pebkac1205

    #2, the one that does NOT have issues after the Recycle of the app pool is a "Web Site" project in visual studio.  ....... The one that does fail after a recycle is a "Web Application" project.

    Web applications (web app or web site) should be written to handle application pool restarts.  

    Are you sure the "Web Site" project is not written to handle a restart?   It's a very common requirement for a web site to handle application pool restarts as well as scale across multiple nodes in a load balanced environment.

    Monday, February 20, 2017 6:19 PM