incubator-wadi-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Strachan <>
Subject Re: [wadi-dev] Re: [Geronimo] Clustering
Date Mon, 19 Dec 2005 15:29:39 GMT
On 19 Dec 2005, at 14:54, Jules Gosnell wrote:
> 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 ?

You said...

>>> but simply a way of locating the  cluster and requesting a  
>>> membership snapshot of it.

The entire purpose of the ActiveCluster APi is to locate members in  
clusters & be informed when they go down. There's a zillion ways of  
implementing this - AC just tries to be a common, simple API we can  

> we really are talking about just a remoting proxy which needs to  
> find, but not 'join' a cluster.

AC can be used purely to discover nodes and choose which one to use  
as a server. The local in-JVM node does not actually have to actually  
advertise itself to members of the cluster if it doesn't wish to -  
thats an implementation detail. (e.g. if you only want servers to be  
discoverable but keep clients invisible).

Using the EJB client and server side example - you may want to know  
which clients are connected to what servers so that you can load  
balance; so even though you may not consider clients as 'members of  
the server cluster' being able to know who is connected to who is  
quite useful. EJB clients could expose statistics that can be used to  
help choose the right server a new node should join.

But whatever - if you don't wanna use the AC API its no big deal; use  
whatever abstraction you see fit - I just wanted to explain the point  
of AC; for discovering nodes in a cluster and being able to choose  
which one to communicate with; it can be implemented any way you like  
(simple multicast stuff, using HTTP, LDAP stuff etc).

Maybe it'd help if we separated AC into the 'messaging' part and the  
'discovery' part?


View raw message