1. 21 Jun, 2014 5 commits
    • antirez's avatar
      New features for CLIENT KILL. · 09dc6dad
      antirez authored
      09dc6dad
    • antirez's avatar
      Assign an unique non-repeating ID to each new client. · cad13223
      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.
      cad13223
    • antirez's avatar
      Client types generalized. · b6a26b52
      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.
      b6a26b52
    • antirez's avatar
      CLIENT LIST speedup via peerid caching + smart allocation. · d8d415e7
      antirez authored
      This commit adds peer ID caching in the client structure plus an API
      change and the use of sdsMakeRoomFor() in order to improve the
      reallocation pattern to generate the CLIENT LIST output.
      
      Both the changes account for a very significant speedup.
      d8d415e7
    • antirez's avatar
      52189cb9
  2. 22 May, 2014 2 commits
    • antirez's avatar
      Process events with processEventsWhileBlocked() when blocked. · f4823497
      antirez authored
      When we are blocked and a few events a processed from time to time, it
      is smarter to call the event handler a few times in order to handle the
      accept, read, write, close cycle of a client in a single pass, otherwise
      there is too much latency added for clients to receive a reply while the
      server is busy in some way (for example during the DB loading).
      f4823497
    • antirez's avatar
      Accept multiple clients per iteration. · f3d3c606
      antirez authored
      When the listening sockets readable event is fired, we have the chance
      to accept multiple clients instead of accepting a single one. This makes
      Redis more responsive when there is a mass-connect event (for example
      after the server startup), and in workloads where a connect-disconnect
      pattern is used often, so that multiple clients are waiting to be
      accepted continuously.
      
      As a side effect, this commit makes the LOADING, BUSY, and similar
      errors much faster to deliver to the client, making Redis more
      responsive when there is to return errors to inform the clients that the
      server is blocked in an not interruptible operation.
      f3d3c606
  3. 23 Apr, 2014 1 commit
  4. 10 Mar, 2014 1 commit
  5. 25 Jan, 2014 1 commit
  6. 25 Dec, 2013 1 commit
  7. 22 Dec, 2013 1 commit
  8. 20 Dec, 2013 1 commit
  9. 11 Dec, 2013 1 commit
  10. 10 Dec, 2013 2 commits
    • antirez's avatar
      Slaves heartbeat while loading RDB files. · 75bf5a4a
      antirez authored
      Starting with Redis 2.8 masters are able to detect timed out slaves,
      while before 2.8 only slaves were able to detect a timed out master.
      
      Now that timeout detection is bi-directional the following problem
      happens as described "in the field" by issue #1449:
      
      1) Master and slave setup with big dataset.
      2) Slave performs the first synchronization, or a full sync
         after a failed partial resync.
      3) Master sends the RDB payload to the slave.
      4) Slave loads this payload.
      5) Master detects the slave as timed out since does not receive back the
         REPLCONF ACK acknowledges.
      
      Here the problem is that the master has no way to know how much the
      slave will take to load the RDB file in memory. The obvious solution is
      to use a greater replication timeout setting, but this is a shame since
      for the 0.1% of operation time we are forced to use a timeout that is
      not what is suited for 99.9% of operation time.
      
      This commit tries to fix this problem with a solution that is a bit of
      an hack, but that modifies little of the replication internals, in order
      to be back ported to 2.8 safely.
      
      During the RDB loading time, we send the master newlines to avoid
      being sensed as timed out. This is the same that the master already does
      while saving the RDB file to still signal its presence to the slave.
      
      The single newline is used because:
      
      1) It can't desync the protocol, as it is only transmitted all or
      nothing.
      2) It can be safely sent while we don't have a client structure for the
      master or in similar situations just with write(2).
      75bf5a4a
    • antirez's avatar
      Handle inline requested terminated with just \n. · 8d0083ba
      antirez authored
      8d0083ba
  11. 05 Dec, 2013 1 commit
  12. 03 Dec, 2013 2 commits
  13. 04 Oct, 2013 1 commit
    • antirez's avatar
      Replication: fix master timeout. · d7fa6d9a
      antirez authored
      Since we started sending REPLCONF ACK from slaves to masters, the
      lastinteraction field of the client structure is always refreshed as
      soon as there is room in the socket output buffer, so masters in timeout
      are detected with too much delay (the socket buffer takes a lot of time
      to be filled by small REPLCONF ACK <number> entries).
      
      This commit only counts data received as interactions with a master,
      solving the issue.
      d7fa6d9a
  14. 27 Aug, 2013 2 commits
  15. 12 Aug, 2013 1 commit
  16. 24 Jul, 2013 2 commits
  17. 17 Jul, 2013 1 commit
  18. 11 Jul, 2013 8 commits
  19. 30 May, 2013 1 commit
  20. 27 May, 2013 2 commits
    • antirez's avatar
      Replication: send REPLCONF ACK to master. · 146f1d7d
      antirez authored
      146f1d7d
    • antirez's avatar
      REPLCONF ACK command. · 1e77b77d
      antirez authored
      This special command is used by the slave to inform the master the
      amount of replication stream it currently consumed.
      
      it does not return anything so that we not need to consume additional
      bandwidth needed by the master to reply something.
      
      The master can do a number of things knowing the amount of stream
      processed, such as understanding the "lag" in bytes of the slave, verify
      if a given command was already processed by the slave, and so forth.
      1e77b77d
  21. 24 May, 2013 3 commits