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