New release and status going forward

[Bela Ban]

jgroups-raft has been a bit dormant lately (mea culpa!), but now that
JGroups is very mature and (more importantly!) people are starting to
use jgroups-raft in *production*, I decided to spend more time in making
it more robust and faster.

Release 1.0.6 has an important change, which uses JGroups (on which
jgroups-raft is riding) better: elections are only triggered when a
JGroups view is received that determines if an election is required
(e.g. majority reached,lost, leader lost). See [1] for details.

Next, I'm going to add additional tests for leader election *edge
cases*, as described in the Raft paper [2] in section 5.4.1 in Fig. 8.

After this, I'm going to implement low hanging performance issues, e.g.
caching of last and previous terms [3], batching of
AppendEntries{Requests,Responses} [4] and removing of synchronization [5].

Currently, preliminary perf tests on 3 Linux 2.6 (older) boxes shows
(cluster of 3, CounterPerf test) between 8'000 and 9'000
updates/sec/node by 300 threads on a shared counter. The perf
improvements above should make this much faster; I'm curious to see just
by how much!

Meanwhile, Francesco has started work on [6] and [7], with the goal of
making the file-based log faster. This is critical, as a read/write is
on the critical path, and so every bit of performance we can squeeze out
of the log will have a great impact on latency, and thus, performance.

It would be nice if folks could give 1.0.6 a try, run benchmarks (e.g.
CounterPerf) and reports numbers/issues/bugs on the issue tracker.

Cheers,

[1] https://github.com/belaban/jgroups-raft/milestone/20
[2] https://raft.github.io/raft.pdf
[3] https://github.com/belaban/jgroups-raft/issues/109
[4] https://github.com/belaban/jgroups-raft/issues/116
[5] https://github.com/belaban/jgroups-raft/issues/110
[6] https://github.com/belaban/jgroups-raft/issues/117
[7] https://github.com/belaban/jgroups-raft/issues/118

--
Bela Ban | http://www.jgroups.org