1. 13 Jan, 2015 1 commit
    • antirez's avatar
      Cluster: clusterMsgDataGossip structure, explict padding + minor stuff. · 45e2a26d
      antirez authored
      Also explicitly set version to 0, add a protocol version define, improve
      comments in the gossip structure.
      
      Note that the structure layout is the same after the change, we are just
      making the padding explicit with an additional not used 16 bits field.
      So this commit is still able to talk with the previous versions of
      cluster nodes.
      45e2a26d
  2. 09 Jan, 2015 1 commit
  3. 03 Dec, 2014 2 commits
  4. 12 Nov, 2014 1 commit
    • antirez's avatar
      Diskless SYNC: fix RDB EOF detection. · 90911905
      antirez authored
      RDB EOF detection was relying on the final part of the RDB transfer to
      be a magic 40 bytes EOF marker. However as the slave is put online
      immediately, and because of sockets timeouts, the replication stream is
      actually contiguous with the RDB file.
      
      This means that to detect the EOF correctly we should either:
      
      1) Scan all the stream searching for the mark. Sucks CPU-wise.
      2) Start to send the replication stream only after an acknowledge.
      3) Implement a proper chunked encoding.
      
      For now solution "2" was picked, so the master does not start to send
      ASAP the stream of commands in the case of diskless replication. We wait
      for the first REPLCONF ACK command from the slave, that certifies us
      that the slave correctly loaded the RDB file and is ready to get more
      data.
      90911905
  5. 29 Oct, 2014 8 commits
  6. 06 Oct, 2014 1 commit
  7. 19 Sep, 2014 1 commit
  8. 08 Sep, 2014 1 commit
  9. 26 Aug, 2014 5 commits
  10. 18 Jul, 2014 8 commits
  11. 27 Jun, 2014 2 commits
    • antirez's avatar
      COMMANDS command renamed COMMAND. · 3364b2d1
      antirez authored
      3364b2d1
    • Matt Stancliff's avatar
      Cluster: Add COMMANDS command · 60d62a99
      Matt Stancliff authored
      COMMANDS returns a nested multibulk reply for each
      command in the command table.  The reply for each
      command contains:
        - command name
        - arity
        - array of command flags
        - start key position
        - end key position
        - key offset step
        - optional: if the keys are not deterministic and
          Redis uses an internal key evaluation function,
          the 6th field appears and is defined as a status
          reply of: REQUIRES ARGUMENT PARSING
      
      Cluster clients need to know where the keys are in each
      command to implement proper routing to cluster nodes.
      
      Redis commands can have multiple keys, keys at offset steps, or other
      issues where you can't always assume the first element after
      the command name is the cluster routing key.
      
      Using the information exposed by COMMANDS, client implementations
      can have live, accurate key extraction details for all commands.
      
      Also implements COMMANDS INFO [commands...] to return only a
      specific set of commands instead of all 160+ commands live in Redis.
      60d62a99
  12. 26 Jun, 2014 1 commit
  13. 23 Jun, 2014 1 commit
  14. 21 Jun, 2014 4 commits
    • antirez's avatar
      New features for CLIENT KILL. · ca262a58
      antirez authored
      ca262a58
    • antirez's avatar
      Assign an unique non-repeating ID to each new client. · b7dd4518
      antirez authored
      This will be used by CLIENT KILL and is also a good way to ensure a
      given client is still the same across CLIENT LIST calls.
      
      The output of CLIENT LIST was modified to include the new ID, but this
      change is considered to be backward compatible as the API does not imply
      you can do positional parsing, since each filed as a different name.
      b7dd4518
    • antirez's avatar
      Client types generalized. · d97d1a64
      antirez authored
      Because of output buffer limits Redis internals had this idea of type of
      clients: normal, pubsub, slave. It is possible to set different output
      buffer limits for the three kinds of clients.
      
      However all the macros and API were named after output buffer limit
      classes, while the idea of a client type is a generic one that can be
      reused.
      
      This commit does two things:
      
      1) Rename the API and defines with more general names.
      2) Change the class of clients executing the MONITOR command from "slave"
         to "normal".
      
      "2" is a good idea because you want to have very special settings for
      slaves, that are not a good idea for MONITOR clients that are instead
      normal clients even if they are conceptually slave-alike (since it is a
      push protocol).
      
      The backward-compatibility breakage resulting from "2" is considered to
      be minimal to care, since MONITOR is a debugging command, and because
      anyway this change is not going to break the format or the behavior, but
      just when a connection is closed on big output buffer issues.
      d97d1a64
    • antirez's avatar
      ROLE command added. · 9b460e80
      antirez authored
      The new ROLE command is designed in order to provide a client with
      informations about the replication in a fast and easy to use way
      compared to the INFO command where the same information is also
      available.
      9b460e80
  15. 09 Jun, 2014 1 commit
    • Matt Stancliff's avatar
      Fix blocking operations from missing new lists · 7fc1fc8c
      Matt Stancliff authored
      Behrad Zari discovered [1] and Josiah reported [2]: if you block
      and wait for a list to exist, but the list creates from
      a non-push command, the blocked client never gets notified.
      
      This commit adds notification of blocked clients into
      the DB layer and away from individual commands.
      
      Lists can be created by [LR]PUSH, SORT..STORE, RENAME, MOVE,
      and RESTORE.  Previously, blocked client notifications were
      only triggered by [LR]PUSH.  Your client would never get
      notified if a list were created by SORT..STORE or RENAME or
      a RESTORE, etc.
      
      Blocked client notification now happens in one unified place:
        - dbAdd() triggers notification when adding a list to the DB
      
      Two new tests are added that fail prior to this commit.
      
      All test pass.
      
      Fixes #1668
      
      [1]: https://groups.google.com/forum/#!topic/redis-db/k4oWfMkN1NU
      [2]: #1668
      7fc1fc8c
  16. 23 May, 2014 2 commits