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 Wed, 12 Jul 2006 09:54:52 GMT
Greg Wilkins wrote:
> All,
> 
> 
> Here are my comments on the Session API that were promised after apachecon dublin.
> This is also CC'd to the wadi list and some of the points are relevant to them 
> as well.
> 
> My own reason for focusing on the Session API when I think about clustering,
> is that I like the idea of pluggable clustering implementations.   Clustering
> is not one size fits all and solutions can go from non-replicated nodes configured
> in a flat file to auto discovered, self healing, redundant hierarchies.
> 
> I think the previous discussions we had on this were making good progress, but
> I think we ran out of steam before the API was improved etc.  So I think it
> worthwhile to re-read the original threads.
> 
> But I will repeat my main unresolved concerns here:
> While I appreciate the keep-it-simple-stupid approach adopted by the proposed
> session API, I remain concerned that it may over simplify and may also mix concerns.
> 
> However, I do think that the API is pitched at about the right level - namely
> that it is below the specific concerns of things such as HTTP.  As the implementor
> of the web container, I would prefer to not delegate HttpSession management
> or request proxying to a pluggable session implementation (I doubt that 
> a cluster impl wants to deal with non-blocking proxying of requests etc.)

I think that our discussions about this have suffered from an ambiguity
around the word 'delegate'...

In one sense of the word, given WADI's current implementation, Jetty
does delegate Session management and HTTP handling to WADI, in that WADI
passes the WebApp/Jetty an object on which it calls a method and the
work in question is done.

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

I would wholeheartedly agree that the code for Http request relocation
should be written by someone with expertise in that area - namely the
container writer. I would just rather see it injected into the clustered
manager, so that it can be called when required, without having to
burden Jetty with the added task of making this decision itself.

> 
> 
> 
> I see that the webcontainer needs to interact with the cluster implementation
> in 4 areas:
> 
> 
> 1) Policy
> ---------
> 
> When a container receives a request, it needs to make a policy decision along 
> the lines of:
> 
>     1) The request can be handled locally.
>     2) The request can be handled locally, but only after some other actions 
>        (eg session is moved to local)
>     3) request cannot be handled locally, but can be redirected to another node
>     4) request cannot be handled locally, but can be proxied to another node.
> 
> This kind of corresponds to the Locator and SessionLocation APIs.  However
> these APIs give the power to enact a policy decision, but give no support to make
> a policy decision.   
> 
> To implement a policy, you might want to use:  the size of the cluster, the total 
> number of sessions, the number of  session on the local node, the number of sessions

> collocated with a remote session, how many requests for the session have recently 
> arrived on what nodes, etc. etc.
> 
> The API does not give me this information and I think it would be 
> difficult to provide all that might be used.  Potentially
> we could get by with a mechanism to store/access cluster wide meta-data
> attributes? 
> 
> However, it is very unlikely that one policy will fit all, so each consumer
> of this Location API will have to implement a pluggable policy frame work of 
> some sorts.
> 
> But as the session API is already a pluggable framework, why don't we 
> just delegate the policy decision to the API.  The web container 
> should make the policy decision, but should call the session API to
> make the decision.  Something like:
> 
>   SessionLocation executeAt =  locator.getSessionExecutionLocation(clientId);
>   if (executeAt.isLocal())
>     // handle request
>   else
>     // proxy or redirect to executeAt location.
> 
> (Note the need for something like this has been discussed before and 
> generally agreed.  I have seen the proposed RemoteSessionStrategy, but I am not 
> sure how you obtain a handle to one - nor do I think the policy should
> decide between redirect and proxy - which is HTTP business).
> 
> 

By exposing the 'policy' api to the container and putting it in charge
of when it used, you are exposing clustering details to it.

WADI's approach is to completely shield the container from having to
know anything about clustering, whilst maintaining contracts with the
container encapsulating various pieces of tier/domain-specific
functionality that may be injected into the clustered session manager.

Clustering is itself a complex domain, just as HTTP and, in the same way
as you want to shield the clustering code from the complexity of HTTP,
we wish to shield you from clustering detail.

> I final concern about location and policy is that the API does
> not support non-homogeneous clusters.  For a given client ID, the 
> EJBSession beans may be on one node and the HttpSession beans on
> another.    So perhaps the type of the session needs to be passed
> to the policy and the policy may decide to only move part of the 
> session around.
> 

You are describing different 'colocation policies'. e.g. 'Colocation'
and 'Dislocation' :-).

I intend to make this a pluggable issue in WADI. In the Geronimo Session
API, since colocation is a little more explicit, this may be awkward...
- but then, you might well argue, that, in an app-server this is a rare
and complex case which you do not feel you need deal with - as has been
suggested to me.

> 
> 
> 2) State.
> 
> The proposed Session interface is where we put the state for
> the session.   The first question about this is why does it not
> implement the Map interface?   The primatives are much the same: 
> 
>    addState(String key, Object value);
>    getState(String key);
>    removeState(String key);
> 
> but without any support for size, iteration, bulk operations etc.
> These operations will be needed to implement getAttributeNames at least.
> 
> Also note that there is not a 1 to 1 mapping between this session object
> and a HttpSession, as for a given client ID there may be a HttpSession for
> each webapp context visited, plus EJB sessions etc.  To handle this,
> the name space of the session must be structured, so when the user calls
> 
>  setAttribute("foo","value");
> 
> the actual call is something like
> 
>  addState("web:"+contextPath+"foo","value");
> 
> Which kind of sux on a number of levels.   First of all contextPath is not 
> sufficiently uniq and virtual hosts and ports must be brought into play.  There
> is also going to be a cost in creating lots of strings just to lookup values.
> 
> I don't see why this scoping could not be done by the session instance 
> itself and that the web container is passed an instance that is pre-scoped to the
> specific context (even if it just added names prefixes behind the scenes).
> 
> 
> Finally, something needs to be done about the events that servlet
> containers need to implement about passivated, binding, invalidation etc.
> This is difficult without making the API servlet specific.  However, I 
> think that some generic binding/passivated event mechanism together with
> an iterator (to discover the values that implement the servlet event listener
> APIs) would be sufficient - we had a rough agreement on that before however
> I was concerned that it was a bit too complex and weblike.
> 
> 

I think that this complexity is all an artifact of the explicit
colocation policy adopted by the API. Once again, it exposes detail to
the container that it just doesn't need - making its job more complex in
the process.

> 
> 3) Life cycle
> 
> Unfortunately the life and death of a session is not simple - specially
> when cross context dispatch is considered.  Session ID's may or may not
> be reused, their uniqueness might need to be guarenteed and the decision
> may depend on the existence of the same session ID in other contexts.
> 
> I think this can be modeled with a structured name space - so perhaps
> this is not an issue anymore?
> 
> 
> 4) Configuration and Management
> It would generally be good to be able to know how many nodes are in
> the cluster (or to set what the nodes are). To be able to monitor node
> status and give commands to gracefully or brutally shutdown a node, move
> sessions etc.
> 
> Clustering aware clients (JNDI stubs, EJB proxies or potentially fancy 
> Ajax web clients) might need to be passed a list of known nodes - but it
> is not possible to obtain/set that from the API - thus every impl will need
> to implement it's own cluster config/discover even if that information is
> available in other implementations.
> 
> 

This is the clustering API (in my mind) that was mooted in the meeting.
A number of clustering substrates (JGroups, ActiveCluster, Tribes,
etc...) have homesteaded this area (WADI maintains an abstraction layer
that can map on to any of these three). All provide an API which
provides membership notification/querying, 1->1 and 1->all messaging
functionality. These are the basic building blocks of clustering and
they will be required in every clustered service that is built for
Geronimo. This is a natural candidate for encapsulation and sharing.
Failing to do this will result in each different service having to build
its own concepts about clustering from the ground up, which would be a
disaster.


Jules



> That is more than enough to ponder for now....
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> So I would like to see an API to which I could delegate this policy decision,
> but I am not sure that the current API with just isLocal() API is rich enough to support
this.
> 
> 
> 
> 
> ---------------------------------------------------------------------
> 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