geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jules Gosnell <>
Subject Re: [wadi-dev] Session/clustering API and the web tier
Date Thu, 13 Jul 2006 19:07:10 GMT

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 ?


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

"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)
  * Open Source Training & Support.

View raw message