geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jules Gosnell <>
Subject Re: [wadi-dev] Re: [Geronimo] Clustering
Date Fri, 06 Jan 2006 12:14:03 GMT
Rajith Attapattu wrote:

> Hmm,  again we have stopped the discussion :). Lets get it started again.

OK - I will pick it up. I've been a bit preoccupied with WADI for a 
while, so apologies for letting this one go cold.

> So can we all come to some agreement (with more discussion) on which 
> direction we might be taking !!
> Like merging ActiveCluster and WADI or getting best of both worlds ?


not sure I follow you here...

are you suggesting merging them because you view them as (a) competing 
or (b) complimentary technologies ?

If (a), then I need to put you straight. WADI is a technology that 
builds on top of ActiveCluster (AC). AC provides basic clustering 
fn-ality (most importantly, a membership abstraction along with 
notifications of membership change).

If (b), then, whilst WADI and AC could be merged, the current separation 
is along clear and modular lines and I see no advantage to collapsing 
the two projects into one.

I think that there is far more reason to consider a merger between 
ActiveSpace (AS). AS is a project that also builds upon ActiveCluster to 
provide distributed caching fn-ality. The fundamental difference (and I 
stand open to correction from James here - I'm not very knowledgeable 
about AS) is that AS provides a host of optimistic caching strategies, 
whilst WADI (currently) provides a single, pessimistic strategy 
specifically designed for the management of state in web and ejb tiers, 
where the sum of the state in the tier is too great to be held by any 
single node. Because WADI and AC fulfil similar roles, I think that 
there is more to be gained by unifying their APIs and code-sharing 
between them. James, if you are reading, what do you think ?

> And also if we can define expectations/requirments for what we like 
> for the next possible release (1.01 or whatever) in terms of 
> clustering would give folks like me more direction as to where we 
> should concentrate on?

Well, I think that there has been plenty of discussion, but you are 
correct in pointing out that there is no grand unified architecture 
document out there. I did start on my suggestions towards one quietly a 
while ago, but canned them. Perhaps enough discussion has now occurred 
to put up a straw man ? Is this what you are looking for ?

> If we decide on a direction maybe a few of us can start on a few 
> prototypes and see what works best for Geronimo.

Rajith, judging from our conversations on this list, your interest seems 
to lie in JNDI clustering ? I think that we need to get you, Gianny 
Damour (working on OpenEJB/WADI integration), James Strachan 
(ActiveSpace) and Kresten Krab (Trifork guy involved in IIOP stuff, 
which needs to be worked into equation) into a thread.

OpenEJB will need cluster aware client-side proxies, delivered from 
HA-JNDI. These proxies will need to talk to EJBs via OpenEJB's 
proprietary protocol and Trifork's IIOP impl (I'm not on my home ground 
here, so I might be off-base - but that is what the thread is for). 
HA-JNDI needs a clustering substrate - ActiveSpace best fits the bill 
(JNDI will be small amounts of data that are write-seldom and read-often).

One other issue that meshes with all of this is deployment. I've given 
some thought to clustered deployment recently and come to the conclusion 
that a deployment/app/?service? is simply a piece of 
write(/[un]deploy)-seldom, read(/invoke)-often data. A deployment may 
result in a number of entries being merged into HA-JNDI, an undeployment 
may result in a number being removed. If a new node joins a cluster (or 
subset of) that is responsible for providing an HA-service/app, then 
that node should deploy an instance of that app as it comes up and 
remove it as it goes down - i.e. a copy of that app should be 
distributed to it and maintained by it for the lifetime of the node, 
just as a jndi entry might be by a distributed JNDI service.

I haven't gone over these ideas with anyone else yet, particularly with 
regards to the relevant JSR, but I guess they need to be thrown out into 
the ring and discussed.

Does everyone think that now is a good time to summarise the various 
discussions that have occurred about clustering into some sort of 
unified structure ? This can then be further discussed and hopefully 
used to carve up work and produce a roadmap ? This is probably over 
ambitious for a 1.0.1 release (it may just be a bug-fix release ?), but 
something that we need to be getting on with.


> Regards,
> Rajith Attapattu.
> On 1/5/06, *Rajith Attapattu* < 
> <>> wrote:
>     -----Original Message-----
>     From: Jules Gosnell [mailto:
>     <>]
>     Sent: Monday, December 19, 2005 9:55 AM
>     To: <>
>     Cc:
>     <>;
>     <>
>     Subject: Re: [wadi-dev] Re: [Geronimo] Clustering
>     James Strachan wrote:
>     >
>     > On 19 Dec 2005, at 14:14, Jules Gosnell wrote:
>     >
>     >> James Strachan wrote:
>     >>
>     >>> On 19 Dec 2005, at 11:53, Jules Gosnell wrote:
>     >>>
>     >>>> , whether there is other suitable Geronimo or ASF-licensed code
>     >>>> available, or whether we will need to write our own WADI-
>     >>>> autodiscovery classes. The important thing is to impose as few
>     >>>> dependencies on the client as possible. The client side code
>     >>>> should  literally be a few lines. Clients using clusters should
>     >>>> not  suddenly find themselves sucking down e.g. the whole of
>     >>>> activemq,  just to do a once off autodiscovery. Early
>     versions of
>     >>>> WADI had its  own autodiscovery code. If we need them, they could
>     >>>> be resuscitated.
>     >>>
>     >>>
>     >>>
>     >>> There's no reason why you can't do a simple implementation of
>     >>> ActiveCluster which doesn't use ActiveMQ - its just a simple API.
>     >>
>     >>
>     >> Sure - but I'm talking about the EJB-client side - where we just
>     >> want to throw across as thin a line as possible, in order to
>     haul a
>     >> decent strength cable back. An EJB client would not need the
>     >> ActiveCluster API (I'm not thinking in terms of making EJB clients
>     >> fully fledged cluster members), but simply a way of locating the
>     >> cluster and requesting a membership snapshot of it.
>     >
>     >
>     > Thats exactly what the ActiveCluster API is for :). Though by all
>     > means come up with another API if you can think of a better way of
>     > doing it.
>     >
>     >> This could be done by just broadcasting a query packet at a well
>     >> known multicast address and waiting for the first well-formed
>     response.
>     >
>     >
>     > Sure - an *implementation* of ActiveCluster API could do exactly
>     that.
>     >
>     ???
>     well, maybe I'm thinking of the wrong piece of activecluster then ?
>     any piece of code could broadcast a packet... which piece of
>     activecluster's API are you suggesting here ?
>     we really are talking about just a remoting proxy which needs to
>     find,
>     but not 'join' a cluster.
>     can you be more specific ?
>     Jules
>     > James
>     > -------
>     >
>     -- 
>     "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.
>     **********************************/

"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