geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Wilkins <>
Subject Session Policy was: heads up: initial contribution of a client API to session state management for OpenEJB, ServiceMix, Lingo and Tuscany
Date Thu, 02 Mar 2006 07:55:10 GMT
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.

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.

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


View raw message