[Spread-users] replicated state machine with spread

José Orlando Pereira jop at lsd.di.uminho.pt
Thu Feb 28 05:17:56 EST 2008

On Wednesday, February 27, 2008, Dan Mihai Dumitriu wrote:
> >
> > That was basically my suspicion, since Flush Spread is actually plain
> > Virtual Synchrony, and closed group semantics are needed so that
> > senders can be blocked during view changes...  Actually we are using
> > the Java API, so is there any way for us to use Flush Spread at all?

On Wednesday 27 February 2008, John Lane Schultz wrote:
> Currently, there is no Java interface to the FL_* calls.  However, a JNI
> wrapper wouldn't be too hard to implement.

There is such JNI wrapper in jGCS (http://jgcs.sf.net). jGCS is a common 
Java interface for multiple GC implementations (think "JDBC for group 
communication"). Both SP_* and FL_* are supported with JNI.

On Wednesday, February 27, 2008, Dan Mihai Dumitriu wrote: 
> > More generally, how would one implement a replicated state machine
> > using basic Spread...?  I was thinking that new members could buffer
> > all incoming messages until such time as they get a state transfer

This is probably the best option, but...

> > (which would need to include the id (lamport time) of the last message
> > applied to the state) from the leader, install that state, and then
> > apply all buffered messages, which have not already been applied to
> > the state.  Senders, including the leader, would need to send messages
> > using the AGREED semantics.  Hmm, I wonder if that would work...

... when performing full state transfer, there is no need for timestamps, 
just: (i) transfer the state immediatly after processing the view change 
event; and (ii) buffer and apply all messages from the view change event.
Note that view change events are always totally ordered regarding regular 
messages, even when not using AGREED.

Jose Orlando Pereira

More information about the Spread-users mailing list