geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gianny Damour <gianny.dam...@optusnet.com.au>
Subject Re: sandbox/messaging - your feedbacks are welcome
Date Tue, 20 Jul 2004 11:36:57 GMT
On 20/07/2004 7:55 PM, Freddi Gyara wrote:

>A couple of suggestions: 
>a) Do we really need to have a specific topology. Since we are using
>Multicast, ALL the servers in the cluster would get the multicast
>packets anyway.
>  
>
You are right: if information is broadcasted to all the servers, then 
one does not need a topology. However, why do we want to send the 
information to all the servers if one only wants to send it to a given 
set of servers?
For instance, in the case of a replication service, the state could be 
replicated to all the servers or only to a specific set. In this latter 
case and as far as I understand, either these packets are unnecessarily 
received by a couple of servers or one sends these packets to a specific 
multicast group only used by the servers that we would like to 
communicate with.
As a matter of fact, this proto uses multicast (UDP) only for its 
heartbeat mechanism and unicast (TCP) for all the other activities.
I think that multicast is useful only for highly redundant data 
distribution. I am not convinced that the replication of HTTP sessions 
needs to be highly redundant. Having said that, I am convinced that 
multicast is the way to go in order to maintain a cluster wide cache.

So, this proto uses the unicast model for peer-to-peer communications. 
It also imposes a specific topology to the servers in order to give full 
control on the way servers are inter-connected. If one wants this server 
to be a direct neighbour (in other word a "prefered" remote server) of 
this other server, then one can achieve that.

>The servers can then work out their "neighbours" through a simple
>(pluggable ?) sort algorithm.
>  
>
This is a great idea. Actually, I had this thought a while back: for 
each server, one configures an ordered list of  servers. When a server 
is started, the first N available servers are considered as their 
"neighbours".

>b) The clustering code should be delineated from the rest of Geronimo
>through a clear set of API.
>Useful functions would include:
>publishToNeighbours(obj): Publishes an object to the server's
>neighbours in the cluster. The identification of neighbours,
>marshalling and transport is left to the clustering layer to decide.
>This would be useful for example, to cluster HttpSessions
>
>publishGlobally(obj): Publishes an object to the entire cluster. eg
>clustered JNDI context.
>  
>
I agree. The proto allows more or less the same kind of operations from 
a semantic point-of-view: it supports the distribution of objects to a 
specified set of servers. For instance, it is possible to create a proxy 
for a service running on N remote servers. When an operation is called 
on this proxy, the invocation is sent to these N remote servers and 
executed. The N results are returned to the proxy, which consolidates 
them and return an "aggregated" result to the caller. You can have a 
look to NodeImplTest.testMulticast for such an example.

Thanks,
Gianny

Mime
View raw message