geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jules Gosnell <ju...@coredevelopers.net>
Subject Re: [Geronimo] Clustering
Date Mon, 19 Dec 2005 14:14:06 GMT
James Strachan wrote:

> On 19 Dec 2005, at 11:53, Jules Gosnell wrote:
>
>> Rajith Attapattu wrote:
>>
>>> Jules,
>>>
>>> Sorry for the late reply and thanks for all the info!!! It's awesome.
>>> I have more questions if you don't mind. Not very organized so  bear 
>>> with me :(
>>>
>> no problem.
>>
>>> Answers are greatly appreciated.
>>>
>>> JNDI implementation
>>> --------------------
>>> I guess what you are talking about is our own version of (at the  
>>> least)JNDI Context implementation that is cluster aware and the  
>>> lookup is based on the various strategies outlined in your email.  
>>> (This is where I guess Apache directory can be leveraged to build  
>>> our impl on top)
>>>
>> I think so.
>>
>> ActiveSpace may be useful here.
>
>
> Agreed - its pretty trivial to use ActiveSpace with its optimistic  
> locking as a provider for JNDI.
>
>
>> The distributed caching problem space is large and varied. wadi- core 
>> is designed very much with a particular subset of this space  in 
>> mind. This is the area concerned with numbers of distributed  objects 
>> that are too great to be held on a single node and that are  
>> frequently written and read and require pessimistic locking  policies 
>> to be used in their manipulation. JNDI has slightly  different 
>> requirements. Objects placed in JNDI are generally few,  rarely 
>> written (only on [un]deployment) and frequently read.  Optimistic 
>> locking policies may be sufficient.
>
>
> For directory services which are very read-centric and performance is  
> an issue, then I'd recommend an optimistic locking mechanism.
>
>
>> Ultimately, wadi-core and ActiveSpace are complimentary  
>> technologies, both providing solutions to different areas of this  
>> problem space. WADI also contains lots of integration code to  
>> various other containers, so I am imagining a situation where a  
>> layer of WADI code integrates Geronimo, Apache Directory and  
>> ActiveSpace, all sitting on top of ActiveCluster and ActiveMQ.
>
>
> FWIW I'd have preferred us to create a 'cluster' subproject at  
> Geronimo where various different kinds of clustering & caching &  
> state management could be unified (plus i'm not keen on WADI as a  
> project name :) - then we can merge the code bases from  
> ActiveCluster, ActiveSpace & WADI into modules which make sense (e.g.  
> pessimistic locking models, optimistic locking models, caching,  
> distributed/movable state etc.).

Agreed - I was just talking with my WADI hat on - let me just remove it 
and put my Geronimo hat on :-) - now that WADI has moved to the 
incubator, these two hats should shortly begin merging into one...

>
>
>
>>> Plus you are taked about passing in membership information to the  
>>> client via a proprietary protocol or the client taking on itself  to 
>>> obtain membership info via configuration or an auto discovery  handle.
>>>
>> Correct. We may well settle on ActiveCluster as the API for  membership.
>
>
> Unless you can come up with a better API, I'd recommend ActiveCluster  
> as its whole design was to act as a simple POJO model for discovery  
> of nodes such that anything can be plugged in the back. Other than  
> reusing a few trivial interfaces from JMS; its easy to implement  
> using any technology whatsoever.

Agreed - I was just being cautious :-)

>
>
>> I am not sure whether we can reuse autodiscovery code from ActiveMQ  
>> (which uses it to connect peers when running on its peer://  protocol 
>> stack)
>
>
> Thats very ActiveMQ transport specific - I'd avoid it if I were you -  
> especially if one of your goals is to avoid having to suck in the  
> whole of ActiveMQ :).

that's what I suspected,

>
>
>> , 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. This could be done by just broadcasting a 
query packet at a well known multicast address and waiting for the first 
well-formed response.


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
 *
 * Open Source Training & Support.
 **********************************/


Mime
View raw message