I pressed 'send' without counting to 10 first on the last response. Sorry.
The thread seems to be getting nowhere fast - probably my fault - let me
try an alternate tack.
here is how I would like to see it work.
The Interception Contract :
The container provides a generic interception point with which the
geronimo session manager (GSM) MAY register an interceptor.
The Policy Contract:
IFF the container chooses to provide invocation/request relocation
fnality it can encapsulate this in an api that knowns nothing about
clusters and everything about relocation and provide this to the GSM layer.
The Relocation Contract :
IFF the container wishes to be involved in decisions around whether to
relocate session or invocation (ultimately about where sessions should
be located) it may do so, via another api (to be discussed when the need
arises). This api will know nothing about clustering, but everything
about the resource usage of a given web container.
...
A request arrives at the boundary of the container which passes it to
the GSM interceptor.
GSM takes control, uses information garnered from its own internals and
potentially from policy contract with the container to decide what to
do. If it wishes to relocate the invocation/request it does so using the
relocation contract and terminates the interception chain. If it wishes
to run the invocation/request locally, it returns flow-control to the
container, allowing the request to continue into it.
That is it.
The container writer need know nothing about custering or session
location. He need not even provide any of the contracts ! - if he
doesn't, the GSM just forgets about invocation relocation and reverts to
shifting state around all the time.
By giving the container any more control over this you will variously:
- duplicate code in every container
- allow different tiers to make conflicting decisions about relocation
- leak clustering issues into container-space.
I've obviously done a bad job of explaining myself so far. Is this clearer ?
Jules
Greg Wilkins wrote:
Jules Gosnell wrote:
James Strachan wrote:
On 7/12/06, Jules Gosnell
Greg Wilkins wrote:
However, in another sense, Jetty need not delegate this task, since the
object returned in these cases is managed by WADI, but created by a
Factory that is injected at startup time. This factory might be
generating instances of a class that has very Jetty-specific knowledge
or is even a part of the Jetty distro...
Thats certainly one approach. Another is for the container to just ask
the policy API what to do (i.e. is the request going to be serviced
locally or not) so that the container can take care of the rest.
This leaks clustering concerns into the container's space.
If the container is going to do the redirecting/proxying (either
directly or as a call back), then it has to be concerned with clustering.
I understand that WADI has an implementation of this, but I want to
be able to use clustering mechanisms other than WADI. I think it is
raising the bar for clustering implementations if they must support
this.
I understand the cleanliness from the session API implementor's
perspective of using a factory and calling back the container when you
see fit - however I also understand the container developers
requirement to understand at all times what each thread is doing, to
tune things aggressively with full knowledge of threading models and
to generally be master of its own domain, so I can understand why a
container developer might prefer a non-callback related solution
(which could introduce all kinds of nasty thread related bugs into the
container).
Any clustering solution will use threads underneath its API. If this is
a concern you should simply make explicit where they may be used.
I don't see why both options can't be offered.
Exactly - why can we not have the simple policy API that we call to
understand what to do.
Jetty can have a session interceptor to call this API and do it's
proxying or redirection and then Jetty can use lots of different
clustering implementations.
But the Jetty developers may be lazy, and instead of implementing their
own interceptor they may choose to use the WADI implementation of it
that wraps up the whole invocation. Tomcat or openEJB may not
be so lazy or have other concerns - thus they might not use the WADI
interceptor but code directly to the policy API.
Agreed. Just some way to ask the Session API if a request can be
processed locally might do the trick, then if not Jetty can do its
proxy/redirect thing. The trickier thing is what to pass into the
strategy to help it decide...
by having Jetty make the decision:
- you leak clustering concerns into the web tier
- you have to duplicate similar code in every clustered tier
Jetty is not making the decision, it is calling an API
to make the decision. Jetty simply implements the execution of
the decision.
The code to do this has to be written for every clustering tier.
Now it is great that WADI wants to write it for every clustering
tier - but that is a big work load and I am not sure that WADI
developers will be able to keep every tier happy and deal with
all of their concerns.
Also, it kind of implies that G will only use WADI. Now I know
that wadi is itself extensible/pluggable/etc. so this might not
be a bad idea. But wadi either has be the G cluster API (and
allow other technologies to be plugged into it), or it has to give up
some of the space (eg implementation of interceptors) to the
tier implementations.
That is a tough call to make at this stage because people just
do not have enough exposure to WADI.
If it was at all possible to have an approach of a low level
API which can either be directly used or used via the WADI
interceptors, then that would give us a chance to evaluate
WADI. If the wadi interceptors are indeed the best, then
great - WADI because the cluster API for G.
So the question is - is the session API good enough to
form the interface between WADI interceptors and WADI
clustering implementations. Originally the answer was no, but
there have been some improvements proposed to the API.
Is that still the case? Eg. with the getExecutionLocation
style API, their is no need for the inefficiencies of
getSessionLocation calls.
Alternately (if wadi understandably does not want to be cleft
in two by the G session API), if somebody writes a clustering
impl behind the G session API (eg the distributed map currently
being worked on), could that be plugged into Wadi as a
pluggable store implementation?
If so, Jetty could just use Wadi and we would get G integration
for free!
cheers
---------------------------------------------------------------------
To unsubscribe from this list please visit:
http://xircles.codehaus.org/manage_email
--
"Open Source is a self-assembling organism. You dangle a piece of
string into a super-saturated solution and a whole operating-system
crystallises out around it."
/**********************************
* Jules Gosnell
* Partner
* Core Developers Network (Europe)
*
* www.coredevelopers.net
*
* Open Source Training & Support.
**********************************/
