[infinispan-dev] RAFT

[Bela Ban]

I read the paper and I'm somewhat less impressed. My major concern (and 
the same holds for Paxos) is that this is slow. Well, as slow as 2PC, to 
be precise... :-)

Sending the change to the coordinator is 1 unicast, then we need 2 
rounds for a change to be 'stable' (they call it 'safe'), ie. agreed 
upon. I guess though that this can be done in the background, and the 
client RPC can return as soon as the server has logged the change into 
its own protocol.

The good thing about Raft is that they chose a fixed coordinator 
(leader) for log replication which means that consensus is only needed 
for leader election and never for log replication, so no 2PC needed 
here. Somewhat similar to sequencer based total order (SEQUENCER)...

Do you guys see this as being potentially beneficial to Infinispan ?

On 16/05/14 17:35, Emmanuel Bernard wrote:
> On Fri 2014-05-16  8:22, Bela Ban wrote:
>> Interesting, thanks for the link !
>> Makes me want to implement this in JGroups. Should be relatively easy
>> with *static* membership. Different ballgame though with dynamic
>> memberships...
>
> That's the same of these approaches. They require a static membership.
> Or number of nodes at least.
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>

-- 
Bela Ban, JGroups lead (http://www.jgroups.org)