Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.
Bug 371041 - Cross context dispatch does not share session id for MongoSessionManager
Summary: Cross context dispatch does not share session id for MongoSessionManager
Status: CLOSED FIXED
Alias: None
Product: Jetty
Classification: RT
Component: server (show other bugs)
Version: 7.6.0   Edit
Hardware: PC Linux
: P3 normal (vote)
Target Milestone: 7.5.x   Edit
Assignee: Jesse McConnell CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-02-09 02:19 EST by Jan Bartel CLA
Modified: 2012-02-09 16:14 EST (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jan Bartel CLA 2012-02-09 02:19:06 EST
See AbstractServerCrossContextSessionTest.

I modified TestServletA and TestServletB to remember the sessionIds that were created on first hit and dispatch respectively. The session ids should be equal, but they are different.

The modified test is checked in to the renewSessionId branch.
Comment 1 Jan Bartel CLA 2012-02-09 02:28:17 EST
I think the isIdInUse test is failing ... its checking to see if the session id that has been presented on the request has the __VALID field set, and it appears not to ... maybe didn't get updated???

Maybe there's an easier test - just look at the in-memory list of _sessionIds and if the id isn't in that list, then nobody is using it? Not sure of any clustering implications with that ... needs some thought.
Comment 2 Jesse McConnell CLA 2012-02-09 13:58:53 EST
" just look at the in-memory list of _sessionIds and if the id isn't in that list, then nobody is using it?"

this won't work as the in memory list is strictly on that node, so should another request have bounced nodes you can't answer the question definitively

looking into the __VALID check
Comment 3 Jesse McConnell CLA 2012-02-09 16:14:14 EST
ok, couple of issues where

1 - i was foolishly trying to set the VALID as a part of the key in the save, that has moved down to the set collection which is how you actually change things in mongodb

2 - i was querying with findOne for an attribute of __valid_false figuring it was defaulting to false should it, think there was a period of time in there where the valid was a false only variable and this process didn't get updated correctly..

regardless, I made the changes to your test from the branch locally, I didn't commit the changes for that test though since I couldn't cherry pick it over cause there were a lot of other changes on that commit and I figured I would save you the merge headache on this issue.  This is workingo on master though with my last commit.

cheers and thanks again