Session state IDs mixed between users

Discussion in 'ASP .Net' started by Lauri Kotilainen, Sep 21, 2005.

  1. 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, Sep 21, 2005
    #1
    1. Advertising

  2. 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, Sep 21, 2005
    #2
    1. Advertising

  3. Lauri Kotilainen

    Mr Newbie Guest

    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.
    Mr Newbie, Sep 21, 2005
    #3
  4. 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, Sep 21, 2005
    #4
  5. Lauri Kotilainen

    Mr Newbie Guest

    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
    Mr Newbie, Sep 21, 2005
    #5
  6. 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, Sep 21, 2005
    #6
  7. Lauri Kotilainen

    Mr Newbie Guest

    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, Sep 21, 2005
    #7
  8. 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
    Lauri Kotilainen, Sep 21, 2005
    #8
  9. Lauri Kotilainen

    Bruce Barker Guest

    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
    >
    Bruce Barker, Sep 21, 2005
    #9
  10. 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, Sep 21, 2005
    #10
  11. Lauri Kotilainen

    Mr Newbie Guest

    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" <> wrote in message
    news:qzgYe.27171$D%...
    > 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, Sep 21, 2005
    #11
  12. 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, Sep 21, 2005
    #12
  13. Lauri Kotilainen

    Mr Newbie Guest

    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" <> wrote in message
    news:CghYe.27198$...
    > 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, Sep 21, 2005
    #13
  14. 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
    Lauri Kotilainen, Sep 21, 2005
    #14
  15. Lauri Kotilainen

    Mr Newbie Guest

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

    Cheers - Mr N


    "Lauri Kotilainen" <> wrote in message
    news:vgiYe.27230$...
    > 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, Sep 21, 2005
    #15
  16. Lauri Kotilainen

    Pennidren

    Joined:
    Feb 13, 2010
    Messages:
    1
    Lauri! Please oh please tell me you figured out what the problem was...!

    I believe I am having the same issue; no statics/shared data in the entire application.
    Pennidren, Feb 13, 2010
    #16
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Sebastian
    Replies:
    0
    Views:
    405
    Sebastian
    May 3, 2004
  2. Philip Tepedino
    Replies:
    3
    Views:
    4,112
  3. Replies:
    2
    Views:
    694
    Beat Bolli
    Jun 21, 2005
  4. Brian Anderson

    Mixed Server Version Session State problem

    Brian Anderson, Dec 5, 2006, in forum: ASP .Net
    Replies:
    2
    Views:
    314
    Brian Anderson
    Dec 5, 2006
  5. archana
    Replies:
    0
    Views:
    331
    archana
    Mar 13, 2007
Loading...

Share This Page