Skip to main content
A
ahmedplummer
Participant
June 25, 2010
Question

session bleed under heavy load...any suggestions?

  • June 25, 2010
  • 1 reply
  • 765 views

hello.

i'm working on an application that has user sensitive data and we are seeing session bleed under heavy load (ie users reporting seeing other users data, error reports with missing session values, things along thoes lines).  the app itself is typical stuff; a user logs in, they see information specific to their user account and do things with it.  some of that information comes from the session.  this all seems to work fine under normal load (100 or less users), or with a few users testing, but fails under heavy load (1000+ concurrent users).  we cannot reporoduce it locally, nor can we see it when we log into the system ourselves and click around during peak load times.

here is some more detail.  as i mentioned, we are storing certain user informaiton in the session.  we use an exclusive lock of the session scope to write that info, and a readonly lock of the session scope to read it (i am quadruple checking this now).  this app is running in a multi-instance clustered environment (all on the same server).  CF8 with IIS.  we are using j2ee session management, with sticky sessions and session  replication on.  we were seeing the session bleed before the clustering was introduced however...

one caveat is that a huge number of our users come from behind a proxy  system, meaning they all have the same IP.  i did some searching on this, but could not find any definitive information that it would create a problem with session variables.

i was wondering if anyone else had seen this kind of problem and/or had any suggestions in dealing with it?

thanks.

This topic has been closed for replies.

1 reply

ilssac
ilssac
Inspiring
June 28, 2010

ahmedplummer wrote:

one caveat is that a huge number of our users come from behind a proxy  system, meaning they all have the same IP.  i did some searching on this, but could not find any definitive information that it would create a problem with session variables.

Session state maintance (by default) requires proper cookies to be sent between each client and the server.  If these cookies are not proplerly maintained session state will not work as expected.  It is not unheard of for a proxy server to mess with cookies on requests going through them.  The the proxy server is caching cookies or in some other way causing the cookies to be shared amoung users, the problem you are describing would exist.

HTH

Ian

A
ahmedplummerAuthor
Participant
June 29, 2010

the jury is still out to a degree, but i think we've identified the culprit(s) of our session bleed for anyone interested.  it boiled down to two problems.

1.  var scoping issues.  unfortunately this was a fairly old application, written before we strictly employed best pracitices on var scoping variables within functions in all our cfc's.  we've fixed the bad code and our session bleed problems seemed to have stopped.  there is a great utility for checking code for var scoping problems available at: http://varscoper.riaforge.org/

2.  a misunderstanding of how cflock with a timeout setting (and no throw on error)  behaves.  aside from session bleed, it turned out we had another issue in there, which was expected session values missing all together.  the crux of the problem is that we had set our cflock read/write timeout's to 30 seconds.  under the extremely heavy load, requests were routinely exceeding those timeout thresholds.  the locks were not set to throw on error, so when the timeout threshold was exceeded, the code within the lock ended up just being skipped.  this was leading to missing data in the session. temporarily we've simply increased the timeout setting to a large number, which has fixed our problem.  eventually we'll set these locks to throw on error and handle the exception in a more graceful manner.

hope this helps someone.

Terms & ConditionsAccessibility statement
Using the community Terms of use Privacy Cookie preferences Do not sell or share my personal information ad choicesAdChoices