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
