geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jules Gosnell <ju...@coredevelopers.net>
Subject Re: [wadi-dev] Session/clustering API and the web tier
Date Thu, 13 Jul 2006 19:09:12 GMT
Jules Gosnell wrote:
> 
> 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:

!!! This is the Relocation 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 :

!!! and this is the Policy 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.
  **********************************/

Mime
View raw message