* rahul valluri <4667...@gmail.com
> [21/07/29 12:44]:
> I am a student trying to implement RAFT on my own using MIT's assignment(am
> not studying there). I am having trouble with a testcase. The test is as
> 1. Initialize 3 servers.
> 2. Add a log entry.
> 3. Disconnect server 1.(Partition, not going offline)
> 4. Add 4 more log entries.
> 5. Connect server 1.
> 6. Add two more logs.
> After adding each log, the code checks whether* the log is committed*. I am
> having trouble getting this state for (6) after (5). When server1 is
> partitioned, it increments its term as timeout happens frequently. So, when
> it connects back, it is having term as *4* while the other partition is
> having *2. *After connection, when the actual leader(say, server 2) sends
> the append entry(in step 6) to server 1, it doesn't add it and sends its
> own higher term as reply. Leader, seeing the higher term in response, goes
> back to follower state. The new entry that server1 rejected is added in
> server 2&3 though(majority). It has the older term - *2.* Now, although
> server1 tries to be leader, it can't because it's log is not up-to-date.
> Ultimately, either of server2 and server3 becomes leader and replicates the
> new entries on server1. Everyone is up-to-date but the latest entry is not
> committed because it is from a previous term. So, the testcase is failing.
> As far as my understanding of the algorithm, the entry should not be
> committed unless there is a new request in current term whose commitment
> makes the previous terms commit by default. So, I would like to know if the
> testcase is wrong or am I doing any step wrong?
You should automatically append a dummy entry to the log after a
leader change, this will commit all previous entries.
Konstantin Osipov, Moscow, Russia