Session state IDs mixed between users

[Lauri Kotilainen]

Hi,

I've already tried several avenues for this, and am quite stumped. The issue
I'm facing is a weird case of sessions getting mixed up (ie. users seeing each
others' data). Apparently this happens at peak load times.

The configuration is W2K3 with ASP.NET 1.1, IIS6.0, Cookieless sessions and
SQL Server as a Session State backend. The problem appears with InProc sessions
as well.

At first I thought I might be using a static variable somewhere to populate
session data, but alas that doesn't seem to be the case.

I wrote a piece of code to act as a simple sanity check -- it stores the
user-agent and IP address of the initial request in the session state, and if
for some reason they don't match on a subsequent request, the user is presented
with an error page and the session data is dumped to a log file.

The log file indicates that several consecutive requests from different hosts
and/or user agents have happened, with the same session id in all of them!

Next I'm thinking maybe I'm doing a Context.Response.Redirect somewhere
that's messing the session id up, but the way I do it is I add the session id to
the redirect URL with Context.Response.ApplyAppPathModifier, and never manually
construct the URL.

(note that this seems to also happen with images I'm generating, and I'm
referring to the images with a relative URL)

Based on my look at the code and a brief glance at the log file it seems that
the obvious points of failure would be the Session State http module or
Context.Response.ApplyAppPathModifier. I'd much rather have the problem in my
code so I could fix it though, so if anyone can offer any pointers to what I
might be doing that causes this, I'd appreciate it.

Thanks for your time,

-Lauri

[Lauri Kotilainen]

Hi,

On a side note, the application is an HttpHandler (all the application code
resides in a single .dll file) that implements IRequiresSessionState.

[Mr Newbie]

If you wrote a simple one page high demand test program to run from multiple
hosts which has the checks you wrote can you still reproduce the symtoms in
the logs.

And are you sure that the log entries are not multiple requests from the
same client. ?

Just thinking aloud !

Mr N

"Lauri Kotilainen" <ry****@gmail.com> wrote in message
news:T5******************@reader1.news.jippii.net. ..

Hi,

On a side note, the application is an HttpHandler (all the application
code resides in a single .dll file) that implements IRequiresSessionState.

[Lauri Kotilainen]

Hi,

Thanks for your reply!

Mr Newbie wrote:

If you wrote a simple one page high demand test program to run from multiple
hosts which has the checks you wrote can you still reproduce the symtoms in
the logs.
Basically I can't reproduce the symptoms at all (we've had test setups where
around a dozen of people do the same things simultaneously). I'm able to test
the logging code since the check compares both the remote address and
user-agent, so if I copy the URL with the session ID to another browser, the
check is triggered.
And are you sure that the log entries are not multiple requests from the
same client. ?

Yes, I'm sure about that. I log the remote IP address, and I can spot several
places in the log where three or four different IPs (from distinctly different
subnets) have made a request with the same session id!

-Lauri

[Mr Newbie]

Im just wondering if this is a cookie issue. Are you using cookieless
operation on all the participating hosts and munging the session ID into the
URL or are you using cookies ?

"Lauri Kotilainen" <ry****@gmail.com> wrote in message
news:Oq*******************@reader1.news.jippii.net ...

Hi,

Thanks for your reply!

Mr Newbie wrote:

If you wrote a simple one page high demand test program to run from
multiple hosts which has the checks you wrote can you still reproduce the
symtoms in the logs.

Basically I can't reproduce the symptoms at all (we've had test setups
where
around a dozen of people do the same things simultaneously). I'm able to
test
the logging code since the check compares both the remote address and
user-agent, so if I copy the URL with the session ID to another browser,
the
check is triggered.

And are you sure that the log entries are not multiple requests from the
same client. ?

Yes, I'm sure about that. I log the remote IP address, and I can spot
several
places in the log where three or four different IPs (from distinctly
different
subnets) have made a request with the same session id!

-Lauri

[Lauri Kotilainen]

Hi again,

Mr Newbie wrote:

Im just wondering if this is a cookie issue. Are you using cookieless
operation on all the participating hosts and munging the session ID into the
URL or are you using cookies ?

As I stated in my initial post, the sessions are cookieless. Instead
of munging the ID manually in the URL, I'm using
HttpContext.Request.ApplyAppPathModifier which should (and indeed, under
normal circumstances *does*) take care of inserting the correct session
ID in the correct place.

-Lauri

[Mr Newbie]

Sorry, I must have missed that.

I'm stumped really sorry to say. Perhaps the way forward it to assert that
the fault is not in the ASP.NET/IIS but lies in your code and attempt to
prove otherwise with a series of controlled tests. The opposite of course is
to assert that there is a bug in ASP.NET./IIS and try and fix it which would
of course be a lot harder if true.

One other possibility of course would be buy a paid incident from Microsoft
and see if they can help. The problem with nebulous and unrepeatable errors
like this is they are rare and hard to find.

I do know a very good ASP.NET well known consultant who may be able to help
you, if you like I could give your email address to him and ask that he
contacts you. He will of course charge. ( I assume you are in the UK ? )

regards mr N

"Lauri Kotilainen" <ry****@gmail.com> wrote in message
news:uM*******************@reader1.news.jippii.net ...

Hi again,

Mr Newbie wrote:

Im just wondering if this is a cookie issue. Are you using cookieless
operation on all the participating hosts and munging the session ID into
the URL or are you using cookies ?

As I stated in my initial post, the sessions are cookieless. Instead
of munging the ID manually in the URL, I'm using
HttpContext.Request.ApplyAppPathModifier which should (and indeed, under
normal circumstances *does*) take care of inserting the correct session
ID in the correct place.

-Lauri

[Lauri Kotilainen]

Mr Newbie wrote:

the fault is not in the ASP.NET/IIS but lies in your code and attempt
to prove otherwise with a series of controlled tests. The opposite
of course is to assert that there is a bug in ASP.NET./IIS and try
and fix it which would of course be a lot harder if true.
As unnatural as it seems, I'm hoping it's my code that's broken
(precisely for the reason you stated above). Of course there is the
remote chance that there is a problem in the HttpModule that's doing the
session handling, and in that case I could always write a session module
myself, but that doesn't sound too likely (or appealing).
One other possibility of course would be buy a paid incident from
Microsoft and see if they can help. The problem with nebulous and
unrepeatable errors like this is they are rare and hard to find.
Thing is, there are a couple of things one can do to *create* a
problem like this, but I went through all the code searching for such
patterns and came up empty handed (of course I might be blind to errors
in my own code).

What's really funny is the app has been running for months without a
single reported incident, and then suddenly a while back this started
happening. Of course it's equally possible that it has happened before
but we just didn't get any reports. In any case, I'll try again to diff
the source tree with the one way back when to see if anything relevant
has changed (did that once already and came back with squat).
I do know a very good ASP.NET well known consultant who may be able
to help you, if you like I could give your email address to him and
ask that he contacts you. He will of course charge. ( I assume you
are in the UK ? )

As a matter of fact I'm not (I'm a finn), and unfortunately a
consultant isn't really an option.

Thanks a lot for trying. I'm still hoping someone will drop me a clue
as to what I might be doing horribly wrong to make this happen :)

-Lauri

[Bruce Barker]

this is almost always a coding error of storing data in a c# static, a vb
public shared, or public variables in a vb module. in all cases the data is
shared between all requests. so naturally users see each others data as
there is only one copy.

-- bruce (sqlwork.com)
"Lauri Kotilainen" <ry****@gmail.com> wrote in message
news:6Q******************@reader1.news.jippii.net. ..

Hi,

I've already tried several avenues for this, and am quite stumped. The
issue
I'm facing is a weird case of sessions getting mixed up (ie. users seeing
each
others' data). Apparently this happens at peak load times.

The configuration is W2K3 with ASP.NET 1.1, IIS6.0, Cookieless sessions
and
SQL Server as a Session State backend. The problem appears with InProc
sessions
as well.

At first I thought I might be using a static variable somewhere to
populate
session data, but alas that doesn't seem to be the case.

I wrote a piece of code to act as a simple sanity check -- it stores the
user-agent and IP address of the initial request in the session state, and
if
for some reason they don't match on a subsequent request, the user is
presented
with an error page and the session data is dumped to a log file.

The log file indicates that several consecutive requests from different
hosts
and/or user agents have happened, with the same session id in all of them!

Next I'm thinking maybe I'm doing a Context.Response.Redirect somewhere
that's messing the session id up, but the way I do it is I add the session
id to
the redirect URL with Context.Response.ApplyAppPathModifier, and never
manually
construct the URL.

(note that this seems to also happen with images I'm generating, and I'm
referring to the images with a relative URL)

Based on my look at the code and a brief glance at the log file it seems
that
the obvious points of failure would be the Session State http module or
Context.Response.ApplyAppPathModifier. I'd much rather have the problem in
my
code so I could fix it though, so if anyone can offer any pointers to what
I
might be doing that causes this, I'd appreciate it.

Thanks for your time,

-Lauri

[Lauri Kotilainen]

Hi,

Bruce Barker wrote:

this is almost always a coding error of storing data in a c# static,
a vb public shared, or public variables in a vb module. in all cases
the data is shared between all requests. so naturally users see each
others data as there is only one copy.

I tried to post a question about this to you on .NET 247 but the
browser swallowed it -- if it's *almost* always, then what are the the
other possibilities?

I have a log file that says people's *session IDs* are changing -- not
the contents of the variables. The logging code dumps all session
variables along with the request URL and session ID, and with absolutely
no exception the variables are consistent (ie. all logged requests that
have the same session ID also have the same values for the variables if
that makes any sense to you), so I can say fairly certainly that the
issue is not storing data in a static variable.

In short, for some reason two or more people are in fact getting the
same session ID. I'm by no means ruling out coding errors though, that
could very well be the cause. I just need to *locate* the problem :)

Thanks for your time,

-Lauri

[Mr Newbie]

One long shot.

One possibility is that there is an issue with caching, I was wondering if
increasing the servers memory has any effect. I Know this is not good
science, but sometimes its worth a try.
Mr N.


"Lauri Kotilainen" <ry****@gmail.com> wrote in message
news:qz*******************@reader1.news.jippii.net ...

Hi,

Bruce Barker wrote:

this is almost always a coding error of storing data in a c# static,
a vb public shared, or public variables in a vb module. in all cases
the data is shared between all requests. so naturally users see each
others data as there is only one copy.

I tried to post a question about this to you on .NET 247 but the
browser swallowed it -- if it's *almost* always, then what are the the
other possibilities?

I have a log file that says people's *session IDs* are changing -- not
the contents of the variables. The logging code dumps all session
variables along with the request URL and session ID, and with absolutely
no exception the variables are consistent (ie. all logged requests that
have the same session ID also have the same values for the variables if
that makes any sense to you), so I can say fairly certainly that the
issue is not storing data in a static variable.

In short, for some reason two or more people are in fact getting the
same session ID. I'm by no means ruling out coding errors though, that
could very well be the cause. I just need to *locate* the problem :)

Thanks for your time,

-Lauri

[Lauri Kotilainen]

Hi again,

Mr Newbie wrote:

One possibility is that there is an issue with caching, I was
wondering if increasing the servers memory has any effect. I Know
this is not good science, but sometimes its worth a try.

Would that be an issue if I'm not using caching? The server is in a
hosted environment (I'm working blind and with a lot of limitations
here), so I can't just drop in another memory stick :(

-Lauri

[Mr Newbie]

The server is using caching regardless of if you asked it to. I realise your
plight and Ive been in similar positions before. All you can do is map your
approach and offer management alternatives against cost/potential.

A memory stick worth £50 may or may not cure the problem, but how much has
it cost you so far in time ?
"Lauri Kotilainen" <ry****@gmail.com> wrote in message
news:Cg******************@reader1.news.jippii.net. ..

Hi again,

Mr Newbie wrote:

One possibility is that there is an issue with caching, I was
wondering if increasing the servers memory has any effect. I Know
this is not good science, but sometimes its worth a try.

Would that be an issue if I'm not using caching? The server is in a
hosted environment (I'm working blind and with a lot of limitations
here), so I can't just drop in another memory stick :(

-Lauri

[Lauri Kotilainen]

Mr Newbie wrote:

The server is using caching regardless of if you asked it to. I
realise your plight and Ive been in similar positions before. All you
can do is map your approach and offer management alternatives
against cost/potential.

Am doing that just now, and I appreciate your input. Still hoping to
code my way out of this though.

I assume the caching you're talking about is not ASP.NET caching,
because I should be able to control that behavior?

The idea that caching would effectively change the URL the user is
requesting -- remember we're talking cookieless sessions here, where the
SID is a part of the URL -- is very weird to say the least.

As the SID is not a query string variable, but rather a part of the
path to the page, I would assume that any normal caching scheme would
consider two URLs with distinctly different SIDs to be completely
different pages (unless the caching is done by ASP.NET in which case the
runtime would know that it's actually the same page with different
variables).

-Lauri

[Mr Newbie]

Well, Im interested to know how this develops ( No Pun Intended ! ). Let
me know.

Cheers - Mr N
"Lauri Kotilainen" <ry****@gmail.com> wrote in message
news:vg******************@reader1.news.jippii.net. ..

Mr Newbie wrote:

The server is using caching regardless of if you asked it to. I realise
your plight and Ive been in similar positions before. All you
can do is map your approach and offer management alternatives
against cost/potential.

Am doing that just now, and I appreciate your input. Still hoping to
code my way out of this though.

I assume the caching you're talking about is not ASP.NET caching,
because I should be able to control that behavior?

The idea that caching would effectively change the URL the user is
requesting -- remember we're talking cookieless sessions here, where the
SID is a part of the URL -- is very weird to say the least.

As the SID is not a query string variable, but rather a part of the
path to the page, I would assume that any normal caching scheme would
consider two URLs with distinctly different SIDs to be completely
different pages (unless the caching is done by ASP.NET in which case the
runtime would know that it's actually the same page with different
variables).

-Lauri