Adar Dembo has posted comments on this change.

Change subject: master_failover-itest: eliminate some flakiness

Patch Set 1:

(1 comment)
Commit Message:

Line 17: 1. Beyond basic EO semantics, RPC results would need to be persisted 
> For writes, we make sure that writes are executed exactly once, and because
Consider the sequence of events I described in the patch, which I'll reprint 

  1. Pause() is issued.
  2. CreateTable() is issued.
  3. Leader master receives CreateTable() and creates the table.
  4. Leader master is paused before the CreateTable() response is sent.
  5. Client times out, finds the new master, and retries CreateTable().
  6. The retry fails because the table was already created in step 3.

The desired semantics are for the client to receive the exact same RPC response 
at the end of step 5 as it would have at the end of step 3 had the old leader 
master not been paused. But, given that in step 5 the client is talking to the 
new leader master, it seems to me that the only way to guarantee the exact RPC 
response is for the old leader master to have replicated it to its followers. 
Otherwise, how would the new leader master know how to build that RPC response?

To view, visit
To unsubscribe, visit

Gerrit-MessageType: comment
Gerrit-Change-Id: Ieba6da4d2a4333760022c68783c32dc2689a8a26
Gerrit-PatchSet: 1
Gerrit-Project: kudu
Gerrit-Branch: master
Gerrit-Owner: Adar Dembo <>
Gerrit-Reviewer: Adar Dembo <>
Gerrit-Reviewer: David Ribeiro Alves <>
Gerrit-Reviewer: Kudu Jenkins
Gerrit-Reviewer: Todd Lipcon <>
Gerrit-HasComments: Yes

Reply via email to