1. 13 Nov, 2013 7 commits
  2. 12 Nov, 2013 10 commits
  3. 11 Nov, 2013 5 commits
    • antirez's avatar
      Sentinel: leadership handling changes WIP. · 8c1bf9a2
      antirez authored
      Changes to leadership handling.
      
      Now the leader gets selected by every Sentinel, for a specified epoch,
      when the SENTINEL is-master-down-by-addr is sent.
      
      This command now includes the runid and the currentEpoch of the instance
      seeking for a vote. The Sentinel only votes a single time in a given
      epoch.
      
      Still a work in progress, does not even compile at this stage.
      8c1bf9a2
    • antirez's avatar
      Sentinel: handle Hello messages received via slaves correctly. · 0bac36d0
      antirez authored
      Even when messages are received via the slave, we should perform
      operations (like adding a new Sentinel) in the context of the master.
      0bac36d0
    • antirez's avatar
      9e1b27d4
    • antirez's avatar
      Sentinel: epoch introduced. · b93b0adc
      antirez authored
      Sentinel state now includes the idea of current epoch and config epoch.
      In the Hello message, that is now published both on masters and slaves,
      a Sentinel no longer just advertises itself but also broadcasts its
      current view of the configuration: the master name / ip / port and its
      current epoch.
      
      Sentinels receiving such information switch to the new master if the
      configuration epoch received is newer and the ip / port of the master
      are indeed different compared to the previos ones.
      b93b0adc
    • antirez's avatar
      b2f83439
  4. 08 Nov, 2013 6 commits
  5. 07 Nov, 2013 2 commits
  6. 06 Nov, 2013 6 commits
  7. 05 Nov, 2013 4 commits
    • antirez's avatar
      Fixed typo in parseScanCursorOrReply(): ad -> at. · 5fd6dee0
      antirez authored
      Thanks to @badboy for reporting it.
      5fd6dee0
    • antirez's avatar
      SCAN code refactored to parse cursor first. · ebcb6251
      antirez authored
      The previous implementation of SCAN parsed the cursor in the generic
      function implementing SCAN, SSCAN, HSCAN and ZSCAN.
      
      The actual higher-level command implementation only checked for empty
      keys and return ASAP in that case. The result was that inverting the
      arguments of, for instance, SSCAN for example and write:
      
          SSCAN 0 key
      
      Instead of
      
          SSCAN key 0
      
      Resulted into no error, since 0 is a non-existing key name very likely.
      Just the iterator returned no elements at all.
      
      In order to fix this issue the code was refactored to extract the
      function to parse the cursor and return the error. Every higher level
      command implementation now parses the cursor and later checks if the key
      exist or not.
      ebcb6251
    • antirez's avatar
      SCAN: when iterating ziplists or intsets always return cursor of 0. · b4048dfe
      antirez authored
      The previous implementation assumed that the first call always happens
      with cursor set to 0, this may not be the case, and we want to return 0
      anyway otherwise the (broken) client code will loop forever.
      b4048dfe
    • antirez's avatar
      101d4bf8