Session cross talk????

[Schworak]

We have one very hevy use web site and we have seen a couple odd happenings where user A is working through the site and some how some of their information gets stored in session variables for user B who logged in at a different time from a different computer in a totally different location.

How can this be? The session ID is not the same for either user either.

Fortunatly, nothing that has crossed is critical but it is unique to the user. I am stumped as to how this might happen and of course it is so rare that it has been impossible to reproduce.

Thoughts?

[BKBK]

Could you please tell how you verified that session information has crossed between users?

[Schworak]

Any time the issue happens we get a crash and this produces a detailed debug report. We noticed the code in one user's session data belonged to a different user. So we started logging this session data every time it got changed by our code.

We can see that the value gets changed. Later we get a crash we see that the single CFSET command has some how loaded the same value into the session data of the user it belonged to plus another user who gets a crash on the next screen they load.

Very confusing!

[Adam Cameron.]

Sounds to me like you might be copying something (like a struct or recordset or something) by reference, so sessions are sharing the same variable.

Is it always the same variable that causes the problem?

--

Adam

[Schworak]

Its the same variable that causes the crash. We can't be sure if other values are also copied yet.

Even if we are using a reference, which I don't think we are since the value is a string and if it was a reference issue wouldn't all users get the same value every time the value changes not just a random (seemingly) one?

[Adam Cameron.]

So it's a string like session.myString?  Not session.someStruct.myString, or session.someObj.myString or session.myQuery.myString (etc)?

It's going to be pretty impossible to do much for you via a forum, because - as you say - it's a load based thing and a code based thing.  Without being able to run the code or see the code, there's nothing much anyone can sensibly say.

You should probably engage a CF config / load / scaling specialist to come in and have a look.  I can recommend Mike Brunt if you're in the States, or Charlie Arehart (obviously they could still be a long way away from you, even if you're somewhere in the States ;-). In the UK, Alex Skinner would be the best I know.  But there'll be someone localish to wherever you are for you to engage, anyhow.

--

Adam

[Schworak]

Yep it is session.mystring not object, query, or struct.\

I figured this was a bit of a long shot in getting help. It is really weird. Session variables are stored in RAM or disk? I am not sure in coldfusion where they are stored and normally I don't care. But now I am starting to care just wondering if this is a storage issue.

[Adam Cameron.]

They're stored in RAM.

Um, you don't have a load-balancer involved in this do you?  I've seen misconfigured LBs screw with sessions in the past by messing up how they pass cookies from client to server.

--

Adam

[Schworak]

I don't think there is a loadbalancer but I will double check that as a possibility with the network team.

[Schworak]

One more thing. It only happens when there are a lot of users on the system at the same time. Always the user count is over 500 if that helps any.

[BKBK]

Schworak wrote:

Any time the issue happens we get a crash and this produces a detailed debug report. We noticed the code in one user's session data belonged to a different user. So we started logging this session data every time it got changed by our code.

We can see that the value gets changed. Later we get a crash we see that the single CFSET command has some how loaded the same value into the session data of the user it belonged to plus another user who gets a crash on the next screen they load.

Very confusing!

Just to help my understanding, could you please confirm whether the scenario is as follows.

When application working normally:

<cfset session.data = dynamic_data>

where dynamic_data is "string 1" for User 1 and "string 2" for User 2.

When crash occurs:

the value of session.data for User 2 becomes "string 1"

[Schworak]

That is correct

[BKBK]

Then my suspicion is not on the session (the left-hand side of the cfset statement), but on the dynamic part that generates and assigns the value (the right-hand side of the cfset statement). Does it, for example, involve locks or application variables?