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 16:22:01 GMT
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.

No - the redirection/proxying is not concerned with clustering - we have 
divided and conquered the idea down to a much smaller concern, that of 
relocating a request to another container (endpoint provided by 
clustering layer):

boolean isRelocatable();
void relocate(EndPoint endPoint); // endpoint is an ip:port

The implementation of this concern is tier-specific and should be 
implemented by the tier owner.

> 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 would far rather WADI didn't have to implement this and that it was 
implemented by Jetty as described. We are getting muddled between what 
WADI currently provides and where I would like to see WADI and the 
g-session-api go.

If the Jetty6 continuations fn-ality complicates the situation, then 
this can be addressed in the API above.

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

This means that it is aware that it is clustered.
The code to call this API and react accordingly will be duplicated in 
every tier.

  Jetty simply implements the execution of
> the decision.

I agree that the tier-ower should provide an implementation of this 
piece of fn-ality. This will not need access to any clustering detail. 
Simply the ip:port of the peer to which you are relocating the 

> 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 

No - I don't - I want the clustered session manager to call the policy, 
and, based on the result of that call, call some tier-specific behaviour 
- see above - very good reasons for this were given in my last mail.

I don't want the container calling the policy, because then you need to 
know that you are clustered - see those reasons.

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


We are talking about a common API here and I am drawing on WADI for 
examples of how I believe it should be done. No specific implementation 
is being suggested.

  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.


and I'm not sure whether you are talking about the session or clustering 
api here.

Both session and clustering apis are completely in the domain of 
Geronimo. If either or both apis are pitched flexibly enough for WADI to 
use them, it will implement them. If implementing them involves 
significant sacrifice of fn-ality, simplicity or performance, then it won't.

As for giving up space, I have no problem with it, provided that there 
is no leakage of concerns as a result of transfer of ownership of said 

> That is a tough call to make at this stage because people just 
> do not have enough exposure to WADI.

N/A - I'm not making that call - just giving the benefit of my 
experience to a design discussion.

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

I'm not asking you to evaluate WADI. I am explaining what I see as 
mistakes in the existing session API, in the hope that change may be made.

Anyone who is interested in WADI is welcome to join our lists and ask 
questions that I will do my best to answer.

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

I still believe not.

My sticking points are as follows (OTTOMH):

1) no exposure of any clustering detail should be made to the client 
container - the existing API will do this, even if it just requires you 
to call a boolean method, test the result and relocate an invocation if 
it it true - reasons given in last mail.

2) no detail of any colocation policy should be exposed to the client 
container - the existing API does this, by exposing implementational 
structure (a map of web session attributes mixed with sessions from 
other tiers) - reasons given in last mail.

3) I would like to see the api provide a cross-tier abstraction with 
which the invocation/request can be encapsulated and manipulated, and 
encourage the provision of optimal, tier-specific implementations of 
invocation relocation fn-ality encapsulated by this interface.

4) I haven't studied the current API closely enough to ascertain how 
apportions responsibility for a number of important issues - session 
lifecycle, notifications, eviction, destruction, ttl, etc... - and I 
don't think that they have been discussed in depth yet - so there may be 
issues here as well.

I concur that some further code (e.g. policy and session impl) will need 
access to expertise from both container and clustering tiers. This 
knowledge should be confined entirely to these code sections.

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

Yes - if someone wrote a WADI/Geronimo adapter. I haven't given it any 
thought, but I do't think that this would pose a problem.


> 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