On Mar 1, 2006, at 11:55 PM, Greg Wilkins wrote:
Dain Sundstrom wrote:
Policy
======
So firstly we need SessionLocatoin.moveto(Server server),
I'm confused. Why would we need that?
There is an API to pull a session to a local node, but there
is no API to push a session to a specific node.
The use-case for the later if you have a load balancer that is
a bit erratic and may scatter requests around a bit (think mod_jk
after it has lost a node).
If you have a policy where every node that receives a request
pulls the session to it, then the session will expensively bounce
around the cluster.
This is something we talked about, and decided that no matter what
you put in your system, you can always end up with a nomadic
session. The solution to this is to slow the migration of the
session so it doesn't have a negative impact on the system.
Basically we implement a "don't move more often then every x minutes"
policy in the system by letting the system that owns a session to
refuse to let it be moved.
Instead you can have a policy where you proxy (or redirect) the
request to the node where the session is. This work fine, but at
the cost of a proxy. If all or most of the requests are being
sent to a specific node, then the session itself should be
able to decide to migrate to that node: "I've been receiving
most of my requests via node 7, so I think I'll move there".
Thus we need a moveTo.
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 see the problem differently. I think the node that is proxying is
paying the cost of the proxy. If that node, decides that proxying is
getting two expensive, it can choose to moveLocally(). I see no need
to have a push function.
but more importantly, when we are redirecting or proxying
requests, it would be good to be able to attach impl
specific meta data to those requests. So the HTTP tier
needs to be able to ask a SessionLocation for an opaque
blob of meta data associated with a request and to be
able to set that meta data when it recieves it.
Huh? Redirect would be dependent on the web container so this
would be
a detail for the web container to deal with. The session apis, only
says, "the session data is on server x". How the web container gets
the request to server x is it's problem.
I totally agree that it is the web-servers problem to
move a request from one node to the other node.
But I think there will be a need for some opaque impl
specific data to be sent with that request - so the
impl can coordinate it's actions.
At the very least, it would be good for a request arriving
on node x to be able to carry the opaque message: "I came from
node z". It is easy for the web container to add such messages,
but there is no way they can be passed to the policy impl.
anyway... this is all getting very abstract... I think
we(I) can let this slide a bit until there are some concrete
policy implementation we can play with.
Cool, I was getting really lost amyway :)
-dain
