incubator-wadi-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Strachan <>
Subject Re: [Geronimo] Clustering
Date Mon, 19 Dec 2005 13:28:51 GMT
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.).

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

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

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


View raw message