losing sessions when running in StateServer mode

[JK]

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.

My first question is: Can application recycling lead to session loss
when running state server ? I've read that this should not.
Is there something else that can reset the sessions when running state
server ?

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>

 

[Mr. Arnold]

<snipped>

Maybe, you should post to this forum.

microsoft.public.inetserver.iis

 

[3P]

Are You saving/deleting any files under Your website's folder structure.

Add logging application restarts to global.asax.

 

[JK]

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.

JM

 

[Mr. Arnold]

3P a écrit :

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.

I don't think you're going to find a magic bullet.

 

[Mr. Arnold]

Whilst it wouldn't do any harm to have cross-posted to
microsoft.public.inetserver.iis (had you cross-posted your reply without
snipping the original that would have done), the state server has
nothing to do with iis and is independent of iis it is very must an
asp.net thing.

To the OP: Whilst I'd not looked into it, I sometimes felt that some
sessions timed-out prematurely, so I'm interested to know if you resolve
it.

It's not my job to cross post for anyone. I pointed the OP in the
direction. It's up to him to sip the water.

 

[JK]

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

 

[Mr. Arnold]

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.

 

[Mr. Arnold]

Mr. Arnold a écrit :


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.

 

[Mr. Arnold]

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?

But what you're talking about is based on using a cookie. What if the
application is not using cookies then what?

 

[JK]

Brian Cryer a écrit :

Two suggestions:

1. Are you calling session.abandon anywhere?

2. Are you resetting the session timeout anywhere? (Not sure if this
works with state-server anyway, but worth asking the question.)

3. Are you running in a web-garden or web-farm environment? A web-garden
is multiple cpus [not cores], but I don't think a web-garden will cause
problems. A web-farm is where you have multiple servers, in this case
you there is a little bit of extra config to ensure that they each use
the same state and don't have the information pertitioned on the
state-service on a per-machine basis - see
http://support.microsoft.com/default.aspx?scid=kb;en-us;325056 for details.

Hi Brian,

Answer is No for 3 questions.

I just had an idea and I'm doing some testing to validate.

My session variable is a Custom Object we created.
If, for any reason, the application is being recompiled, maybe the
object stored in state server will be lost.
I'm tyring to see whether simple variables (e.g Integers) are also lost.

Thanks for all,
JM

 

[JK]

Mr. Arnold a écrit :

But what you're talking about is based on using a cookie. What if the
application is not using cookies then what?

I think you should read the Microsoft documentation on this.
All is explained.

JM

 

[JK]

Brian Cryer a écrit :

a recompile (which is why I don't do that any more), so it probably also
applies to state. This of course assumes a recompile. If you are not
recompiling then it shouldn't matter nor should a recycle of the worker
process make any difference.

I'm not recompiling but sometimes it is done automatically when files
are changed. Note that the object stored in the session has not been
changed for ages.

Do look to see whether the sessionID is being preserved.

I can check the cookie on the client. Is there something to check on the
server ?

Thanks,
JM

 

[Mr. Arnold]

Don't know. It could store it as a separate variable in the HTML much
like viewstate or even in the viewstate, but I'm speculating because I
don't know what asp.net does. This isn't something I've looked at.

If something (like not using cookies) interferes with the session-id so
its lost then yes that could account for what the OP is seeing - which
is why I've posted suggesting he look at whether the session-id is
preserved when the session is lost.

You know, I had a situation where I had a custom object in session with
many object graphs in it that was being passed around from page to page,
and the pages populated the object and object graphs in the custom object.

All this was in-proc, and if session timed-out, IIS reset, the user got
up and walked way for days and came back to the machine with the browser
still opened on one of these pages, the application had to get the
custom object back and put it back into session as if nothing had happened.

On every page-unload, I would spawn a thread, serialized the object and
sent it to my custom SQL server state table for this particular
application.

All I had to do was to detect that the custom object was null in memory,
and I went back to my state table and get the last known object back,
deserialized it and put the object back into session.

The objects were not saved to my state table based on a session-id and
there was other information I could use like user-id and a couple of
other ID(s) in the session being used by the user that made things
unique for my state records.

If things are that critical and you have to get the object back based on
a last version that was successfully saved, I don't think I would be
depending upon a session state service of SQL State server to do it.


That's how I look at it.

 

[JK]

Brian Cryer a écrit :

Simply display the value of Session.SessionID (or
HttpContext.Current.Session.SessionID). Nothing more complex than that.
For a given browser session as far as I'm aware this should never change
- even across a session timeout. If it does change then that would
account for the loss of session information, so the next task would be
to identify why its changed.

Brian,

I think you were right. It seems that my session ID has changed.
Here my log where I print sessions:
21/07/2010 12:36 : -- SESSION ID is:hghggu45kp3zfg55kiovs0ae timeout:60
21/07/2010 12:36 : -- USER ID is: 1
21/07/2010 12:36 : -- USER IS admin
21/07/2010 13:29 : -- SESSION ID is:yplwhojtqpox5uizuri4m434 timeout:60
21/07/2010 13:29 : -- USER IS NOTHING!!

I just go to lunch (so there were no activity on both client and server)
and then, the session ID has changed.

How can this be possible ?

JM

 

[Mr. Arnold]

<snipped>

After watching this whole abomination with an ASP.NET State service and a
custom object, I now know to avoid it at all cost, and do it myself. That
also includes not doing it with a SQL Server State server too.

 

[Mr. Arnold]

SQL Server state is a whole lot slower. Never used it myself.

I have used it in a couple of shops. It was OK, and I didn't really see any
performance issues using a SQL State server.

If you had been following the thread closely you will have seen that the
problem turns out to be that the session-id is being lost. (Session-id is
not itself stored in the session.) If the session-id is being lost then
this will affect any session regardless of the mechanism used to main it
(in-proc, state or sql server). If you can suggest how the OP might
investigate the cause of this then that would be helpful.

The easiest thing to do would be to have a base page that all other pages
are derived from, and the base page would have a hidden field that would
hold the Session-ID that was saved on initial access of the application, and
other pages can access the basepage.SessionID.

Given that the problem turns out to have nothing to do with using state
service, to referring to it as an "abomination" is just daft.

No, it's about the manner in which State Service is being used in this
situation that I find questionable. There are other ways to keep a custom
object in state without depending upon State Service.

 

[Mr. Arnold]

Good to know. TA.


But this is just re-implementing what the framework is supposed to be
doing for us anyway.
That said, it might be the basis for quite a good work around - hope the
OP is still paying attention!


Okay, I see where you are coming from. Fair enough.

I had a situation where I couldn't use the session-id, which would have
been concatenated at the end of a session custom object name that needed
to be passed around from page to page. The reason I couldn't use the
session-id is another story, and I don't want to get into it.

And my solution was to ToString() a Guid and concatenated the GUID to
session custom object name. So the application started up on a certain
page when doing a creation of user information, and it started-up on
certain page when maintenance was being done to the existing user
information.

The original GUID assigned had to be passed from page to page to
construct the session object name for the custom object to set/get
session object.

How I did it was the two pages that were used for create/maint would
initially get a new GUID at page-load !postback. It would save the
string Guid to a hidden field, which was on all the pages for this
application. As each page did a redirect to another page, the GUID was
taken from the hidden field and passed on the URL.

The pages would determine at their page-load if it was a postback or
not. It was not a postback (redirect from another page), the page would
querystring for the GUID on the URL and save it to its hidden field for
the GUID. If it was a postback then, the page would go to the hidden
field to get the GUID, because the URL no-longer had the GUID on the URL
on postback. In either case, I always had the initial GUID that was
trapped on my two start pages to be passed around to the other pages to
construct the session variable name to get/set.

Even if the page timed-out, the GUID was not lost as the page kept GUID
using a hidden field state.

If one is not inclined to use a base page to hold Session-ID, one could
use what I have talked about to trap the Session-ID and pass it around
and not loose it.

 

[3P]

If things are that critical and you have to get the object back based on

a last version that was successfully saved, I don't think I would be
depending upon a session state service of SQL State server to do it.


That's how I look at it.

Because this is custom logic. Not typical session usage.

Can I ask if You did some performance measuring? What I find weird is
spawning another thread in
PageUnload. Thus You use two worker threads for each client and that will
decrease performance of
application.

 

[3P]

One of the advantages in using the stateserver for state is that it
doesn't matter if the application gets recycled. Recycling is only an
issue with state if you use in-proc.

I didn't pay enough attention to OP. I didn't notice it was state-server.