1. 24 Mar, 2022 1 commit
  2. 13 Mar, 2022 1 commit
  3. 15 Nov, 2021 1 commit
  4. 03 Nov, 2021 1 commit
    • Shaya Potter's avatar
      set next_idx on each succesful raft_send_appendentries call (#65) · 02bdf818
      Shaya Potter authored
      this is to avoid sending duplicate entries each time raft_send_appendentries is called, just because they haven't been acked yet.
      
      it will still be reset backwards upon the leader receiving a raft_recv_appendentries_response() with a failure mode
      
      + a test for next_idx on append entry, which changes a number of tests which checked for this
      
      in order to do this, I had to modify the existing mock callback to return 0 instead of 1.  this needs to be verified
      
      + fixes for raft tests that this change exposed
      
      1) when we issues a sequence of entries, each was given an increasing term, so had entries whose term was higher than leaders term
      
      so had to fix that
      
      2) by setting the term of appendentries_repsonse to not be equal to leaders term (because of fix above), we now fail on receiving them
      
      do all that by not allowing raft_append_entry to append an entry that break raft semantics (i.e. term of entry > log term), but this breaks many tests that don't set term, so set them
      02bdf818
  5. 15 Sep, 2021 1 commit
  6. 01 Sep, 2021 1 commit
    • Shaya Potter's avatar
      include the prev_log_idx in the appendentry response (#45) · 64747dee
      Shaya Potter authored
      the problem we have is that 2 appendentries can be in process in parallel
      
      Howver, the response handler doesn't expect this, it will reset the next_idx in both, but currently resets next_idx based on next_idx's value, not the old value that was the basis of prev_log_idx.
      
      Solution: return prev_log_idx in the response
      
      Problem with solution: prev_log_idx is not always based on next_idx from node, but can be based on a snapshot idx if it no longer exists. I haven't coded this yet, but perhaps can determine if the prev_log_idx that is returned is the snapshot_idx and if so, then dont increment by 1. Its possible we could pass even another flag into the appendentries struct to say if its a snapshot, but that's ugly.
      
      In addition, we increment msg_id on each appendentries so that if a response comes back out of order and we have already accepted the later response, we just ignore this response.
      
      In addition, on appendentry response, even if the appendentry wasn't a success, as long as its the same term as us (i.e. we are still the leader) then for leader/quorum purposes, that is sufficient, so move up set_last_ack to right after term test.
      64747dee
  7. 31 Aug, 2021 1 commit
  8. 01 Aug, 2021 1 commit
  9. 27 Jul, 2021 1 commit
    • Shaya Potter's avatar
      match up raft_get_last_log_term() to should_grant_vote() (#14) · fab583d6
      Shaya Potter authored
      raft_get_last_log_term() is used for filling in vote requests, except it didn't match 100% with the logic in should_grant_vote
      
      * update test to prove that change works as needed
      
      previous test tested when we don't snapshot everything, but code was broken when we did.
      modified test tested only when we snapshot everything, now we do both in sequence.
      
      * use raft_get_last_log_term in __should_grant_vote()
      
      also modify __should_grant_vote to take a raft_server_t instead of raft_server_privat_t so its not constantly casting it to void.
      fab583d6
  10. 18 Dec, 2018 1 commit
  11. 09 Dec, 2018 1 commit
  12. 06 Dec, 2018 1 commit
  13. 18 Nov, 2018 1 commit
  14. 08 Oct, 2018 1 commit
  15. 27 Sep, 2018 2 commits
    • Yossi Gottlieb's avatar
      AE error response not properly handled. · 5e336b8f
      Yossi Gottlieb authored
      Errors were ignored if node's match_idx==next_idx-1, I assume (??) as a
      precaution against silently feeding a node that is not monotonic.
      
      However this does not consider the case where send_appendentries()
      relies on snapshot_last_idx which may be greater than the node's index.
      5e336b8f
    • Yossi Gottlieb's avatar
      AE error response not properly handled. · b5cf5cf9
      Yossi Gottlieb authored
      Errors were ignored if node's match_idx==next_idx-1, I assume (??) as a
      precaution against silently feeding a node that is not monotonic.
      
      However this does not consider the case where send_appendentries()
      relies on snapshot_last_idx which may be greater than the node's index.
      b5cf5cf9
  16. 16 Aug, 2018 1 commit
  17. 15 Aug, 2018 1 commit
  18. 07 Aug, 2018 2 commits
  19. 20 Jun, 2018 1 commit
  20. 07 Jun, 2018 1 commit
    • Willem Thiart's avatar
      Remove RAFT_LOGTYPE_SNAPSHOT · 700eebe6
      Willem Thiart authored
      The RAFT_LOGTYPE_SNAPSHOT was a bad design choice. It's better to not
      have this marker entry so that users don't have to check for the log
      entry type in the callbacks. Also, loading a snapshot correctly created
      this marker entry, but the compaction side did not. It's better to
      remove this log type than to fix this asymmetry.
      
      Fixes the following edge cases:
      - Server crashes if the last snapshot index is N and a appendentries
      message pops entries all the way back to index N.
      - Server sends an appendentries message with an invalid prev_log_idx and
      prev_log_term, causing the peer to crash.
      700eebe6
  21. 24 May, 2018 1 commit
  22. 16 May, 2018 1 commit
  23. 11 Apr, 2018 1 commit
  24. 09 Jan, 2018 1 commit
  25. 08 Jan, 2018 1 commit