Re: sandbox/messaging - your feedbacks are welcome

[Gianny Damour]

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