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 Fri, 03 Mar 2006 02:24:39 GMT

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

Mime
View raw message