losing sessions when running in StateServer mode
in [ASP .NET]
|
Prev: System.Web.IHttpHandler, System.Web.SessionState.IRequiresSess
Next: Looking for a NNTP server that discuss csharp/.net
From: Brian Cryer on 20 Jul 2010 05:12 "JK" <JK(a)invalid.com> wrote in message news:4c45642e$0$27598$ba4acef3(a)reader.news.orange.fr... > 3P a �crit : >> Are You saving/deleting any files under Your website's folder structure. >> >> Add logging application restarts to global.asax. > > I have no global.asax. > However, when running state server, is that important ? > I've read somewhere that unless you restart state server, you never lose > sessions variables. That is (or should be) correct. You only loose your session if you are using in-proc. If you wanted to force your session to be abandoned you would either call session.abandon or (sledge-hammer approach) restart the asp.net state service. Now, if your asp.net state service were restarting for some reason (unlikly) then you would loose all state information, but I'd expect that to be recorded in your logs and I've personally never encountered that as a problem. -- Brian Cryer http://www.cryer.co.uk/brian
From: Mr. Arnold on 20 Jul 2010 05:21 On 7/20/2010 5:10 AM, Brian Cryer wrote: > "Mr. Arnold" <Arnold(a)Arnold.com> wrote in message > news:u7$DQp%23JLHA.1868(a)TK2MSFTNGP05.phx.gbl... >> On 7/20/2010 4:54 AM, JK wrote: >>> 3P a �crit : >>>> Are You saving/deleting any files under Your website's folder >>>> structure. >>>> >>>> Add logging application restarts to global.asax. >>> >>> I have no global.asax. >>> However, when running state server, is that important ? >>> I've read somewhere that unless you restart state server, you never lose >>> sessions variables. >>> >> >> But how would an application know about the session variables it had >> when W3WP.exe was recycled?. Everything is lost I would think. And >> that must be the case, because you're talking about even with a >> session start server in the infrastructure. > > All variables are lost yes, but not session unless you are using > in-proc. With state-server the session information is serialized and > stored in a separate asp.net state server process. The session ID is > stored in a cookie (I think), so is available to the server on each > post-back or page-refresh, and it uses this to retrieve session > information from the asp.net state server process. So session > information is preserved across a recycle (which can be very useful when > debugging as you can compile and then continue without having to re-login). But if the session is lost by the application how is IIS going to know what session information belonged to what application? I don't think IIS is doing application tracking too with a state server. Now maybe, the programmer can take over and program for it in the application and go after the state information and restore it. But without doing that, I don't see how it's going to get session back for the application without some type of intervention initiated by the application itself.
From: Brian Cryer on 20 Jul 2010 05:23 "JK" <JK(a)invalid.com> wrote in message news:4c454d12$0$2983$ba4acef3(a)reader.news.orange.fr... > Hi All, > > We have problem with the session timeout. It is supposed to be 1 hour but > the sessions variable are lost before that. > I did some testings and the sessions are lost after a random number of > minutes (35, 41, 44, 54, ....). > I've checked the servers (Win Server 2003) application event logs and > found nothing. > It's a single server setup, no web farms and no load balancing. Out of curiosity, when you seem to loose session, is the sessionID correct? If for any reason your sessionID were being corrupted then that might give the appearance of your session being lost. (So dump out your session-ID before and after the session is lost, provided you don't close the browser the session-id should remain constant.) > My first question is: Can application recycling lead to session loss when > running state server ? I've read that this should not. No. > Is there something else that can reset the sessions when running state > server ? As far as I'm aware only if you do it explicitly, and in any event I'd expect to see it recorded in the system event log. > Thanks, > JM > > IIS6 Settings > 1. Recycle worker processes (in minutes) = 1740 > 2. Recycle worker processes (number of requests) = Unchecked > 3. Recycle worker processes at the following times = Unchecked > 4. Maximum virtual memory = Unchecked > 5. Maximum used memory = Unchecked > 6. Shutdown worker processes after being idle = 200 > 7. Limit the kernel request queue = 1000 > 8. Everthing else = Unchecked > > <!-- Web.Config Configuration File --> > <configuration> > <system.web> > <httpRuntime executionTimeout="10800" /> > <sessionState mode="StateServer" > stateConnectionString="tcpip=localhost:42424" timeout="60"></sessionState> > <authentication mode="Windows"> > <forms timeout="60"></forms> > </authentication> > <customErrors mode="Off"/> > <globalization > fileEncoding="iso-8859-1" > requestEncoding="iso-8859-1" > responseEncoding="iso-8859-1" > /> <compilation debug="true"/> > </system.web> > </configuration> I doubt its relevant, but do you know what the default setting is for cookieless is? I have cookiless="false" in my sessionState config. -- Brian Cryer http://www.cryer.co.uk/brian
From: Mr. Arnold on 20 Jul 2010 05:27 On 7/20/2010 5:11 AM, JK wrote: > Mr. Arnold a �crit : > >> >> But how would an application know about the session variables it had >> when W3WP.exe was recycled?. Everything is lost I would think. And >> that must be the case, because you're talking about even with a >> session start server in the infrastructure. >> > > Because the sessions variables are held by the state server! > It seems it is designed for this. > > JM No, I don't think so, and I think you have a miss understanding as to what is really happening when session is lost and you recycled WPW3.exe. Why would you be talking about this, if things are working the way you think it is and session information is somehow to comeback as is when things have been disrupted for an application.
From: Brian Cryer on 20 Jul 2010 05:32
"Mr. Arnold" <Arnold(a)Arnold.com> wrote in message news:%23DOd7z%23JLHA.3732(a)TK2MSFTNGP02.phx.gbl... > On 7/20/2010 5:10 AM, Brian Cryer wrote: >> "Mr. Arnold" <Arnold(a)Arnold.com> wrote in message >> news:u7$DQp%23JLHA.1868(a)TK2MSFTNGP05.phx.gbl... >>> On 7/20/2010 4:54 AM, JK wrote: >>>> 3P a �crit : >>>>> Are You saving/deleting any files under Your website's folder >>>>> structure. >>>>> >>>>> Add logging application restarts to global.asax. >>>> >>>> I have no global.asax. >>>> However, when running state server, is that important ? >>>> I've read somewhere that unless you restart state server, you never >>>> lose >>>> sessions variables. >>>> >>> >>> But how would an application know about the session variables it had >>> when W3WP.exe was recycled?. Everything is lost I would think. And >>> that must be the case, because you're talking about even with a >>> session start server in the infrastructure. >> >> All variables are lost yes, but not session unless you are using >> in-proc. With state-server the session information is serialized and >> stored in a separate asp.net state server process. The session ID is >> stored in a cookie (I think), so is available to the server on each >> post-back or page-refresh, and it uses this to retrieve session >> information from the asp.net state server process. So session >> information is preserved across a recycle (which can be very useful when >> debugging as you can compile and then continue without having to >> re-login). > > But if the session is lost by the application how is IIS going to know > what session information belonged to what application? I don't think IIS > is doing application tracking too with a state server. Now maybe, the > programmer can take over and program for it in the application and go > after the state information and restore it. > > But without doing that, I don't see how it's going to get session back > for the application without some type of intervention initiated by the > application itself. Sorry I thought I explained that. The session-id is sent to the browser, normally in a cookie. It is then posted back to the server on every post-back or page-refresh. So the server (by which I mean the asp.net framework running on the server, not IIS which couldn't care less) always has the session-id. So the session-id is always available. The session-id is then used when the asp.net state service is contacted to retrieve the session information. That is how session information is preserved across a recycle. Now, if you use in-proc then the session information would be stored in the worker process so if the worker process were recycled then the session information would be lost. The OP is using state-server so the session information is stored externally to the worker process and thus is preserved across a recycle. Does that help clarify things? -- Brian Cryer http://www.cryer.co.uk/brian |