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] Re: [Geronimo] Clustering
Date Fri, 06 Jan 2006 16:31:08 GMT
Matt Hogstrom wrote:

> Jules, I think you are spot on with a summary at this point.  At least 
> in my conversations a person's view of clustering is influenced by 
> which aspect of clustering they are intersted in.  I think a short doc 
> would be really helpful here.  Were you planning on doing that or 
> would you like some help?

Matt,

The more I look at the amount of work that needs doing the more help I 
think I need !

I am away this weekend, but I will try to put together a document 
skeleton early next week that defines the areas that we need to cover. 
Then we can refer back to various discussions on the list to flesh out 
the relevant areas. I'm not sure of the best way of making this document 
available so that everyone can contribute - but we can worry about that 
when we have one.

Do you have a pet clustering area ? Have we discussed it ?

Jules

>
> Jules Gosnell wrote:
>
>> 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 ?
>>
>>
>>
>> hmmm...
>>
>> 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.
>>
>>
>> Jules
>>
>>>  
>>> Regards,
>>>  
>>> Rajith Attapattu.
>>>
>>>  
>>> On 1/5/06, *Rajith Attapattu* <rajith.attapattu@redknee.com 
>>> <mailto:rajith.attapattu@redknee.com>> wrote:
>>>
>>>
>>>
>>>     -----Original Message-----
>>>     From: Jules Gosnell [mailto: jules@coredevelopers.net
>>>     <mailto:jules@coredevelopers.net>]
>>>     Sent: Monday, December 19, 2005 9:55 AM
>>>     To: dev@wadi.codehaus.org <mailto:dev@wadi.codehaus.org>
>>>     Cc: wadi-dev@incubator.apache.org
>>>     <mailto:wadi-dev@incubator.apache.org>; dev@geronimo.apache.org
>>>     <mailto:dev@geronimo.apache.org>
>>>     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
>>>     > -------
>>>     > http://radio.weblogs.com/0112098/
>>>
>>>
>>>
>>>     --     "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 <http://www.coredevelopers.net>
>>>     *
>>>     * 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)
 *
 *    www.coredevelopers.net
 *
 * Open Source Training & Support.
 **********************************/


Mime
View raw message