geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dain Sundstrom <d...@iq80.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 Tue, 07 Mar 2006 17:35:00 GMT
On Mar 6, 2006, at 1:01 AM, Greg Wilkins wrote:

> 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.

I think this should be implemented under the covers of the Session  
API.  This third party controller, will have to be specific to the  
implementation anyway, since it will need custom metadata from each  
node to make decisions, and therefore it can communicate with the  
node using a custom interface that includes a moveTo method.

I say if over time we discover that everyone implementing the session  
API are adding this feature, and there is a desire for these groups  
to interop, we can discuss adding such a feature then.

-dain

Mime
View raw message