Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@geronimo.apache.org
Received-SPF: pass (asf.osuosl.org: domain of james.strachan@gmail.com
 designates 64.233.184.196 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:mime-version:in-reply-to:references:content-type:message-id:content-transfer-encoding:from:subject:date:to:x-mailer;
        b=FKr8yLIEwEoFhi+Fy/t/CfKfkmo4vWS/Gmdj2ucozWDF5KiWu5EKrBR41TH4rA1yDhP1CwkdCeabsScqvVw8rxn68W24XThQZwGUBUJqkQXAEmx8gH/cV10Pa+EmqdfIWRaO1h+Ay8oErHQmQFOeKArDVvhKGwVECQymoRnAunk=
Mime-Version: 1.0 (Apple Message framework v746.2)
In-Reply-To: <4406A4DE.2070603@mortbay.com>
References: <1F5F68F5-2E35-4AAF-B90B-072081D34FE7@gmail.com>
 <44042DE9.2080203@mortbay.com>
 <F10E5C28-9354-4C62-84B8-2FA718F27720@iq80.com>
 <4406A4DE.2070603@mortbay.com>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <F73B8531-71F1-47A7-8382-716075FA6932@gmail.com>
Content-Transfer-Encoding: 7bit
From: James Strachan <james.strachan@gmail.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, 3 Mar 2006 18:20:10 +0000
To: dev@geronimo.apache.org

On 2 Mar 2006, at 07:55, 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.

Note you can proxy or redirect - you don't have to move it locally


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

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

Yeah; when proxying/redirecting we need some way to pass in some  
information so that the Policy/container can make better session- 
movement decisions. Though I think thats a nice to have - a real  
simple algorithm (like the one in SVN) could well work for lots of folks

http://svn.apache.org/repos/asf/geronimo/trunk/modules/session/src/ 
java/org/apache/geronimo/session/remote/util/ 
DefaultRemoteSessionStrategy.java

James
-------
http://radio.weblogs.com/0112098/