Question about updating the next index for a specific follower

[Zishan Shaikh]

The original paper says that once the leader sees that appendentry is successful/acknowledged (i.e. a follower has responded positively with the append request), then the next index & the match index for that follower index should be updated. For instance, say nextindex 10 for follower B was succesfully acknowledged, leader updates nextindex as 11 and matchindex as 10 for that follower B.

Now, what if a new client request arrives on the leader before the follower could respond to the previous appendentry of nextindex 10 from the leader?

When the leader will try to append the new request to its own log and try to replicate it on the follower B, it will still see the nextindex 10 for the new request (as the request arrived before the leader could increment nextindex in the response context) and replicate it on the follower.

What happens in this scenario and when is the right time to increment nextindex for a follower to avoid the race above?
What can be the solution to the race above?

[Oren Eini (Ayende Rahien)]

The typical way it works is that you don't have concurrent sends to the follower, or if you do, you have enough information in the reply to get the context out

There is no point in having parallel sends to the follower, it is only going to process them one at a time anyway

Hibernating Rhinos Ltd  

Oren Eini l CEO l Mobile: + 972-52-548-6969

Office: +972-4-622-7811 l Fax: +972-153-4-622-7811

 

--
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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[jordan.h...@gmail.com]

There's nothing that says a leader needs to immediately send an AppendEntries RPC when a command is received, and indeed that would be contrary to the concept of batching that's built into AppendEntries RPCs. Typically, the leader just ensures that only one AppendEntries RPC is in progress to a given follower at a time. When new writes are received, they're appended to the log and will normally be sent in the next batch to the follower once any in-progress AppendEntries RPC returns. 

But it would also be perfectly fine for the leader to immediately send a second AppendEntries RPC, optimistically assuming the follower will respond successfully to the in progress AppendEntries RPC. If the follower rejects the first, it will reject the second as well. If it accepts the first, it will accept the second as well. This would amount to a sloppy/inefficient implementation of pipelining.

--

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.