«

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

Hi,

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

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" <> wrote in message
news:T5cYe.26948$. ..
> Hi,
>
> On a side note, the application is an HttpHandler (all the application
> code resides in a single .dll file) that implements IRequiresSessionState.

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

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" <> wrote in message
news:OqdYe.27091$_ ...
> 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

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

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" <> wrote in message
news:uMeYe.27128$ ...
> 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 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

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" <> wrote in message
news:6Q8Ye.26888$. ..
> 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
>

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