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/