Question regarding committing previous term.

[rahul valluri]

Hello,

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 follows:

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?

[Oren Eini (Ayende Rahien)]

Yes, that is expected, look at the noop commit that the leader generates after election.

It will force the commit to happen for all previous entries as well.

Also, take a look at early voting / trial election option, Server 1 will typically not increment the term unless it was able to reach a majority that said they'll vote for soemone in the election

--
You received this message because you are subscribed to the Google Groups "raft-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to raft-dev+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/raft-dev/3c1f5d4a-a4fb-4817-acbe-ede9d7e2c248n%40googlegroups.com.

--

Oren Eini CEO   /   Hibernating Rhinos LTD Mobile:  972-52-548-6969 Sales:  sa...@ravendb.net Skype:  ayenderahien Support:  sup...@ravendb.net

[Konstantin Osipov]

* rahul valluri <4667...@gmail.com> [21/07/29 12:44]:

> Hello,
>
> 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
> follows:
>
> 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

[rahul valluri]

Thank you. Will add a no-op entry. But I didn't understand the suggestion of early voting. Is there any article which explains it? I couldn't find any. 

I understood that I should not increment the term in server1 if I neither received RequestVote replies nor any leader's heartbeat. So, essentially once a server goes into candidate mode, it has only one term number throughout. But what if there are two candidates and both don't get majority? Even if one of them has a timeout, its next request(with same term as its previous RequestVote) will get a failed reply since the peers have already voted in that term. Or is the condition for not incrementing the term strictly when no message is received?

[Oren Eini (Ayende Rahien)]

Sorry, the usual term for that is PreVote, see the discussion here: (section 5):

https://www.openlife.cc/sites/default/files/4-modifications-for-Raft-consensus.pdf

To view this discussion on the web visit https://groups.google.com/d/msgid/raft-dev/e3e69572-47ea-4cfa-a95b-a5801d658663n%40googlegroups.com.

[rahul valluri]

Cool. Will read it. Thank you.