geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Wilkins <gr...@mortbay.com>
Subject Re: Session Policy was: heads up: initial contribution of a client API to session state management for OpenEJB, ServiceMix, Lingo and Tuscany
Date Mon, 06 Mar 2006 09:01:17 GMT


James Strachan wrote:

>> I think a moveTo will also be useful for implementing shutdown
>> policies, where you want to gently take a node out of a cluster.
>> The policy should be able to be written independently of impl.
> 
> 
> I don't think the non-web world needs it that much as there typically 
> isn't a crazy load balancer in the way smoking crack and doing wacky 
> stuff.
> 
> Both moveHere and moveThere could very well be valid decisions that 
> either the container or some Policy class can choose to do - I'd just 
> like to explore the use case a little further to check there is a  need.
> BTW I don't think its a huge biggie as moveHere and moveThere  are kinda
> similar.
> 
> Normally when a request hits a node the session is here or its 
> overThere. So the use case you are suggesting is, the session is 
> locally here but the node decides to move the session overThere -  then
> it must redirect/proxy the current request to overThere right?  It
> probably wants to do that to give the load balancer a clue of  where the
> session really is; in which case the redirected/proxied  request will
> have the session locally - then it can decide if its  gonna move the
> session or not. The complication of the node who owns  a session
> deciding where to send it is that she doesn't know what the  other nodes
> are doing per se; which is why its easier to do the moves  from the
> other way around. i.e. the node thats getting hit a lot  decides to grab
> the session. A node that rarely gets hit doesn't know  which node is
> really getting hammered per se - so why not proxy/ redirect and let that
> guy decide?
> 
> Like I say - no biggie either way - just wanting to clarify if we 
> really need this.


In the context of a request being receive, the choice is almost
always going to be between: 1) proxy request   and  2) move session Local.

So moveTo is not needed in that case.

moveTo is needed in the cases outside of the context of a request:

  If the policy algorithm wants to shutdown a node, it can move
  requests away from that node.

  If the policy algorithm does not evaluate how well balanced it
  is on every request, but every few seconds - then it may detect
  misplaced sessions and need to move them.     Note that an individual
  node receiving an individual request is unlikely to have sufficient
  information to make the correct choice between proxy and moveLocal -
  it will be a guess and some meta evaluation will be needed to balance
  the cluster.

  Ditto for when you have a programable load balancer - some meta
  policy might need to balance the cluster and move sessions around.


At the end of the day, I think if we drop moveLocal and just have moveTo
(which covers the moveLocal case) - then we cover all bases and have
very little extra complexity in the API.

cheers


    















Mime
View raw message