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
|