1. 06 Mar, 2013 1 commit
    • antirez's avatar
      API to lookup commands with their original name. · 7b190a08
      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.
      7b190a08
  2. 20 Feb, 2013 1 commit
  3. 12 Feb, 2013 1 commit
  4. 08 Feb, 2013 1 commit
  5. 05 Feb, 2013 1 commit
  6. 28 Jan, 2013 1 commit
    • antirez's avatar
      Fix decrRefCount() prototype from void to robj pointer. · 8766e810
      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.
      8766e810
  7. 19 Jan, 2013 3 commits
  8. 15 Jan, 2013 2 commits
    • antirez's avatar
      Typo fixed, ASCI -> ASCII. · 9b89ab06
      antirez authored
      9b89ab06
    • antirez's avatar
      CLIENT GETNAME and CLIENT SETNAME introduced. · 1971740f
      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.
      1971740f
  9. 03 Jan, 2013 1 commit
  10. 03 Dec, 2012 1 commit
    • antirez's avatar
      Memory leak fixed: release client's bpop->keys dictionary. · ab2924cf
      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.
      ab2924cf
  11. 02 Dec, 2012 1 commit
    • antirez's avatar
      Blocking POP: use a dictionary to store keys clinet side. · 2f87cf8b
      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.
      2f87cf8b
  12. 08 Nov, 2012 1 commit
  13. 01 Nov, 2012 2 commits
  14. 27 Jun, 2012 1 commit
    • antirez's avatar
      REPLCONF internal command introduced. · 3a328978
      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.
      3a328978
  15. 15 Jun, 2012 1 commit
    • antirez's avatar
      Fix c->reply_bytes computation in setDeferredMultiBulkLength() · 5b63ccce
      antirez authored
      In order to implement reply buffer limits introduced in 2.6 and useful
      to close the connection under user-selected circumastances of big output
      buffers (for instance slow consumers in pub/sub, a blocked slave, and so
      forth) Redis takes a counter with the amount of used memory in objects
      inside the output list stored into c->reply.
      
      The computation was broken in the function setDeferredMultiBulkLength(),
      in the case the object was glued with the next one. This caused the
      c->reply_bytes field to go out of sync, be subtracted more than needed,
      and wrap back near to ULONG_MAX values.
      
      This commit fixes this bug and adds an assertion that is able to trap
      this class of problems.
      
      This problem was discovered looking at the INFO output of an unrelated
      issue (issue #547).
      5b63ccce
  16. 07 Apr, 2012 1 commit
  17. 29 Mar, 2012 2 commits
  18. 27 Mar, 2012 1 commit
  19. 14 Mar, 2012 1 commit
  20. 13 Mar, 2012 4 commits
  21. 07 Mar, 2012 1 commit
  22. 16 Feb, 2012 1 commit
  23. 07 Feb, 2012 2 commits
  24. 06 Feb, 2012 1 commit
  25. 04 Feb, 2012 2 commits
    • antirez's avatar
      This fixes issue #327, is a very complex fix (unfortunately), details: · f6b32c14
      antirez authored
      1) sendReplyToClient() now no longer stops transferring data to a single
      client in the case we are out of memory (maxmemory-wise).
      
      2) in processCommand() the idea of we being out of memory is no longer
      the naive zmalloc_used_memory() > server.maxmemory. To say if we can
      accept or not write queries is up to the return value of
      freeMemoryIfNeeded(), that has full control about that.
      
      3) freeMemoryIfNeeded() now does its math without considering output
      buffers size. But at the same time it can't let the output buffers to
      put us too much outside the max memory limit, so at the same time it
      makes sure there is enough effort into delivering the output buffers to
      the slaves, calling the write handler directly.
      
      This three changes are the result of many tests, I found (partially
      empirically) that is the best way to address the problem, but maybe
      we'll find better solutions in the future.
      f6b32c14
    • antirez's avatar
      Use less memory when emitting the protocol, by using more shared objects for... · 355f8591
      antirez authored
      Use less memory when emitting the protocol, by using more shared objects for commonly emitted parts of the protocol.
      355f8591
  26. 25 Jan, 2012 1 commit
  27. 24 Jan, 2012 4 commits