incubator-wadi-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 Mon, 19 Dec 2005 17:25:48 GMT
James Strachan wrote:

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


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

OK - I see - but I'm not sure that I am drawn to this approach :-)

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

Its not that I don't want to use AC client side - its that I don't see 
clients as being members of the cluster in any way - passive or active.

but, I guess this opens up an interesting topic...

I'm thinking in terms of relatively large numbers of clients to servers.

I wasn't thinking in terms of clients receiving any notifications about 
changes in cluster membership or state location.

This is probably because WADI comes from a background in which the 
client is completely dumb, but also because a server may support many 
thousands of clients. I see the overhead of trying to pessimistically 
keep these clients in sync with developments within the cluster as 
outweighing the benefit. The architecture that I have in mind is more 
optimistic. It waits for something exceptional to happen - e.g. some 
state migrating as its node shuts down followed by a client for that 
state trying to make a call to it - then pays a small but exceptional 
cost in terms of a fail-over (which may become an autodiscovery in the 
even more exceptional case that all nodes in the cluster have been 
cycled between successive calls from the client).

Thus, in the usecase that I expect, I think that the optimistic approach 
will be more efficient than the more pessimistic. However you should 
expect the unexpected - right :-)

I guess that this way of thinking has prevented me from seeing clients 
as cluster members.... when perhaps they might be seen that way ?

Perhaps we could look at how AC impls auto discover cluster members, 
then abstract that out into another interface (Client) which Node could 
inherit/make use of ?

Perhaps we could even have different Client implementations - Optimistic 
as I envisage and Pessimistic with targeted backchat coming from the 
cluster about relevant membership and state location changes (although I 
guess this means running some sort of server within the client stub?).

I guess this means that the Optimistic stub is a Client and the 
Pessimistic stub a Node (which listens but does not join the Cluster and 
isa Client also).

How does that sound ?


> Maybe it'd help if we separated AC into the 'messaging' part and the  
> 'discovery' part?
> 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.

View raw message