Sacha Labourey wrote: > Hello Jules, > > >>I have recently been thinking a bit about my next iteration on >>distributable HttpSessions for JBoss/Jetty. > > > BTW, does it work?!? I haven't heard you anymore since your last troubles. >
I have still not been able to get two JBoss instances to recognise each other - but then I haven't tried very hard. My job finishes on th 26th, the baby is due on the 27th. I'm having a few days off, then I will be rereading all this mail and sorting out my cluster. Until then, Jules > >>My reading of the spec is that it avoids all of these issues by only >>ever allowing one copy of a session to be active at one time i.e. it >>talks about migrating sessions from one server to another - but not (as >>I recall) replicating them. > > > This is what we tend to have: only one session is active at a time. (minus side >effects) > > BTW, I think that, not only for HttpSession but for JMS, one important service is >missing from the HA framework: some kind of distributed locking mechanism (i.e. the >way to say "this belongs to me"). It wasn't needed until now but the distributed >cache/httpsession/queues/... will heavily rely on this, I am pretty sure. > > >>I see the following problems with replication : >> >>1. create/modify/destroy session events >>---------------------------------------- >> >>If a session is created/modified/removed on NodeA, should listeners >>attached to a replicant (or the replicant's context) be notified >>on NodeB ? > > > Currently, the session is removed from the cache from NodeB. The question is: Why >would you have two session active at a time? (I know: multi-frames). If we have n >frames that read and 1 frame that write (which is the case in most cases IMHO), it is >ok. But I agree: without a load-balancer supporting sticky session, we can have some >strange behaviour. > > But iMHO, we have to find a mean between performance and "correctness" in this case. >If you want to be sure that only one session is active at a time and this, without a >sticky session LB, then it means distributed locking, no other choice. > > >>If so, we open another nasty can of worms, since we need to guarantee >>the order in which modifications arrive at NodeB from other Nodes in the >>cluster. > > > That's the issue: non sticky-session LB. > > Sticky => performance > non-Sticky => distributed locking => bad performance > > I wanted to implement the locking service for a further release of JBoss. > > >>Furthermore, code that manages distributed resources via these >>notifications, and work in the webapp in non-distributed mode, may >>break. e.g. code that allocates/deallocates a distributed resource on >>session creation/destruction will have to reference count >>creation/destruction so that the resource is allocated/deallocated at >>the correct times. Even then, if a node goes down, serious problems >>arise - the system begins to look very fragile. > > > I know not enough on the servlet side to have a critical eye on this, so I trust you >;) > > >>If not, then we assume that all resources being managed by these >>listeners are distributed and not local, since notifications involving >>different parts of their lifecycle may arrive on different nodes in the >>cluster. > > > distributed? no: performance would be dead. > > >>2. activation/passivation/distribution >>--------------------------------------- >> >>The spec requires notification of the relevant listeners on the >>activation/passivation of a session. Ignoring the problem in (1) another >>issue still remains. Does the distribution of a session constitute a >>passivation/activation cycle ? >> >>Let's say we start a new nodeB and deploy a webapp on it. This webapp is >>already running on another nodeA. A request for this webapp somehow >>arrives at nodeB. Does nodeB notify activation listeners ? If so, then >>for the sake of symmetry, nodeA should have notified passivation >>listeners. Pursuing this to it's logical conclusion, every 'snapshot' >>and distribution of a session might need to notify first passivation >>and then activation listeners. Activation/Passivation is too expensive >>to do this frequently. > > > See above. > > >>I am interested in how others have resolved these problems, or have they >>been largely ignored in other implementations ? >> >>In writing this I am beginning to think in the following way : >> >>The spec resolves all of this by only allowing one 'active' copy of the >>session at any one time. I think that one way around these problems may >>be to assume that only one replicant at any one time is 'active'. >>Notification of change is only made on the 'active' session. The token >>designating 'activity' is passed around the cluster in the form of >>client requests. If we can avoid two requests accessing twin sessions on >>different nodes at the same time we can adhere to the spec's model of >>how this should work. Session affinity will go most of the way to >>fulfilling this requirement, but there will be cases when it will fail. >>In these cases, behaviour will be unpredictable - can we prevent this ? >> >> >>OK - I'm rambling, and it's past my bedtime. >> >> >>Does this make any sense to anyone ? > > > Jules, you always make sense. That's probably because you know your family until >1066 ;) You have one thousand year of short stories as a basis for your thinking ;) > > Cheers, > > > Sacha > > > ------------------------ Yahoo! Groups Sponsor ---------------------~--> > HOT! PRICE BREAKTHROUGH! > SUPER Tiny Wireless Video Camera UNDER $80 BUCKS --> ORDER NOW! > http://us.click.yahoo.com/y7toOC/8o6DAA/yigFAA/CefplB/TM > ---------------------------------------------------------------------~-> > > For the latest information about Jetty, please see http://jetty.mortbay.org > > To alter your subscription to this list goto >http://groups.yahoo.com/group/jetty-discuss > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ > > _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
