1. 03 Dec, 2013 2 commits
  2. 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
  3. 27 Aug, 2013 2 commits
  4. 12 Aug, 2013 1 commit
  5. 24 Jul, 2013 2 commits
  6. 17 Jul, 2013 1 commit
  7. 11 Jul, 2013 8 commits
  8. 30 May, 2013 1 commit
  9. 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
  10. 24 May, 2013 3 commits
  11. 06 Mar, 2013 1 commit
    • antirez's avatar
      API to lookup commands with their original name. · bc1b2e8f
      antirez authored
      A new server.orig_commands table was added to the server structure, this
      contains a copy of the commant table unaffected by rename-command
      statements in redis.conf.
      
      A new API lookupCommandOrOriginal() was added that checks both tables,
      new first, old later, so that rewriteClientCommandVector() and friends
      can lookup commands with their new or original name in order to fix the
      client->cmd pointer when the argument vector is renamed.
      
      This fixes the segfault of issue #986, but does not fix a wider range of
      problems resulting from renaming commands that actually operate on data
      and are registered into the AOF file or propagated to slaves... That is
      command renaming should be handled with care.
      bc1b2e8f
  12. 12 Feb, 2013 1 commit
  13. 11 Feb, 2013 1 commit
  14. 05 Feb, 2013 1 commit
  15. 28 Jan, 2013 1 commit
    • antirez's avatar
      Fix decrRefCount() prototype from void to robj pointer. · 2825f21f
      antirez authored
      decrRefCount used to get its argument as a void* pointer in order to be
      used as destructor where a 'void free_object(void*)' prototype is
      expected. However this made simpler to introduce bugs by freeing the
      wrong pointer. This commit fixes the argument type and introduces a new
      wrapper called decrRefCountVoid() that can be used when the void*
      argument is needed.
      2825f21f
  16. 19 Jan, 2013 3 commits
  17. 15 Jan, 2013 2 commits
    • antirez's avatar
      Typo fixed, ASCI -> ASCII. · f31d10b9
      antirez authored
      f31d10b9
    • antirez's avatar
      CLIENT GETNAME and CLIENT SETNAME introduced. · 786bd393
      antirez authored
      Sometimes it is much simpler to debug complex Redis installations if it
      is possible to assign clients a name that is displayed in the CLIENT
      LIST output.
      
      This is the case, for example, for "leaked" connections. The ability to
      provide a name to the client makes it quite trivial to understand what
      is the part of the code implementing the client not releasing the
      resources appropriately.
      
      Behavior:
      
          CLIENT SETNAME: set a name for the client, or remove the current
                          name if an empty name is set.
          CLIENT GETNAME: get the current name, or a nil.
          CLIENT LIST: now displays the client name if any.
      
      Thanks to Mark Gravell for pushing this idea forward.
      786bd393
  18. 03 Jan, 2013 1 commit
  19. 03 Dec, 2012 1 commit
    • antirez's avatar
      Memory leak fixed: release client's bpop->keys dictionary. · 124cb6dd
      antirez authored
      Refactoring performed after issue #801 resolution (see commit
      2f87cf8b) introduced a memory leak that
      is fixed by this commit.
      
      I simply forgot to free the new allocated dictionary in the client
      structure trusting the output of "make test" on OSX.
      
      However due to changes in the "leaks" utility the test was no longer
      testing memory leaks. This problem was also fixed.
      
      Fortunately the CI test running at ci.redis.io spotted the bug in the
      valgrind run.
      
      The leak never ended into a stable release.
      124cb6dd
  20. 02 Dec, 2012 1 commit
    • antirez's avatar
      Blocking POP: use a dictionary to store keys clinet side. · 07a9f854
      antirez authored
      To store the keys we block for during a blocking pop operation, in the
      case the client is blocked for more data to arrive, we used a simple
      linear array of redis objects, in the blockingState structure:
      
          robj **keys;
          int count;
      
      However in order to fix issue #801 we also use a dictionary in order to
      avoid to end in the blocked clients queue for the same key multiple
      times with the same client.
      
      The dictionary was only temporary, just to avoid duplicates, but since
      we create / destroy it there is no point in doing this duplicated work,
      so this commit simply use a dictionary as the main structure to store
      the keys we are blocked for. So instead of the previous fields we now
      just have:
      
          dict *keys;
      
      This simplifies the code and reduces the work done by the server during
      a blocking POP operation.
      07a9f854
  21. 08 Nov, 2012 1 commit
  22. 01 Nov, 2012 2 commits
  23. 07 Jul, 2012 1 commit
    • antirez's avatar
      REPLCONF internal command introduced. · dbd8c753
      antirez authored
      The REPLCONF command is an internal command (not designed to be directly
      used by normal clients) that allows a slave to set some replication
      related state in the master before issuing SYNC to start the
      replication.
      
      The initial motivation for this command, and the only reason currently
      it is used by the implementation, is to let the slave instance
      communicate its listening port to the slave, so that the master can
      show all the slaves with their listening ports in the "replication"
      section of the INFO output.
      
      This allows clients to auto discover and query all the slaves attached
      into a master.
      
      Currently only a single option of the REPLCONF command is supported, and
      it is called "listening-port", so the slave now starts the replication
      process with something like the following chat:
      
          REPLCONF listening-prot 6380
          SYNC
      
      Note that this works even if the master is an older version of Redis and
      does not understand REPLCONF, because the slave ignores the REPLCONF
      error.
      
      In the future REPLCONF can be used for partial replication and other
      replication related features where there is the need to exchange
      information between master and slave.
      
      NOTE: This commit also fixes a bug: the INFO outout already carried
      information about slaves, but the port was broken, and was obtained
      with getpeername(2), so it was actually just the ephemeral port used
      by the slave to connect to the master as a client.
      dbd8c753