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/
