1. 21 Jan, 2013 7 commits
  2. 19 Jan, 2013 9 commits
  3. 18 Jan, 2013 3 commits
  4. 17 Jan, 2013 1 commit
  5. 16 Jan, 2013 3 commits
  6. 15 Jan, 2013 4 commits
    • antirez's avatar
      Tests for CLIENT GETNAME/SETNAME. · ea1f503c
      antirez authored
      ea1f503c
    • 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
    • antirez's avatar
      Undo slave-master handshake when SLAVEOF sets a new slave. · ef99e146
      antirez authored
      Issue #828 shows how Redis was not correctly undoing a non-blocking
      connection attempt with the previous master when the master was set to a
      new address using the SLAVEOF command.
      
      This was also a result of lack of refactoring, so now there is a
      function to cancel the non blocking handshake with the master.
      The new function is now used when SLAVEOF NO ONE is called or when
      SLAVEOF is used to set the master to a different address.
      ef99e146
  7. 11 Jan, 2013 1 commit
  8. 10 Jan, 2013 3 commits
  9. 09 Jan, 2013 1 commit
  10. 03 Jan, 2013 2 commits
  11. 20 Dec, 2012 1 commit
  12. 17 Dec, 2012 2 commits
  13. 14 Dec, 2012 1 commit
    • antirez's avatar
      serverCron() frequency is now a runtime parameter (was REDIS_HZ). · f1481d4a
      antirez authored
      REDIS_HZ is the frequency our serverCron() function is called with.
      A more frequent call to this function results into less latency when the
      server is trying to handle very expansive background operations like
      mass expires of a lot of keys at the same time.
      
      Redis 2.4 used to have an HZ of 10. This was good enough with almost
      every setup, but the incremental key expiration algorithm was working a
      bit better under *extreme* pressure when HZ was set to 100 for Redis
      2.6.
      
      However for most users a latency spike of 30 milliseconds when million
      of keys are expiring at the same time is acceptable, on the other hand a
      default HZ of 100 in Redis 2.6 was causing idle instances to use some
      CPU time compared to Redis 2.4. The CPU usage was in the order of 0.3%
      for an idle instance, however this is a shame as more energy is consumed
      by the server, if not important resources.
      
      This commit introduces HZ as a runtime parameter, that can be queried by
      INFO or CONFIG GET, and can be modified with CONFIG SET. At the same
      time the default frequency is set back to 10.
      
      In this way we default to a sane value of 10, but allows users to
      easily switch to values up to 500 for near real-time applications if
      needed and if they are willing to pay this small CPU usage penalty.
      f1481d4a
  14. 12 Dec, 2012 2 commits