1. 27 Jul, 2015 2 commits
  2. 26 Jul, 2015 6 commits
  3. 17 Jul, 2015 1 commit
  4. 16 Jul, 2015 2 commits
    • antirez's avatar
      Client timeout handling improved. · 25e1cb3f
      antirez authored
      The previos attempt to process each client at least once every ten
      seconds was not a good idea, because:
      
      1. Usually because of the past min iterations set to 50, you get much
      better processing period most of the times.
      
      2. However when there are many clients and a normal setting for
      server.hz, the edge case is triggered, and waiting 10 seconds for a
      BLPOP that asked for 1 second is not ok.
      
      3. Moreover, because of the high min-itereations limit of 50, when HZ
      was set to an high value, the actual behavior was to process a lot of
      clients per second.
      
      Also the function checking for timeouts called gettimeofday() at each
      iteration which can be costly.
      
      The new implementation will try to process each client once per second,
      gets the current time as argument, and does not attempt to process more
      than 5 clients per iteration if not needed.
      
      So now:
      
      1. The CPU usage of an idle Redis process is the same or better.
      2. The CPU usage of a busy Redis process is the same or better.
      3. However a non trivial amount of work may be performed per iteration
      when there are many many clients. In this particular case the user may
      want to raise the "HZ" value if needed.
      
      Btw with 4000 clients it was still not possible to noticy any actual
      latency created by processing 400 clients per second, since the work
      performed for each client is pretty small.
      25e1cb3f
    • antirez's avatar
      Clarify a comment in clientsCron(). · e0bb454a
      antirez authored
      e0bb454a
  5. 13 Jul, 2015 2 commits
    • antirez's avatar
      EXISTS is now variadic. · 4c7ee0d5
      antirez authored
      The new return value is the number of keys existing, among the ones
      specified in the command line, counting the same key multiple times if
      given multiple times (and if it exists).
      
      See PR #2667.
      4c7ee0d5
    • antirez's avatar
      Geo: fix command table keys position indexes for three commands. · 5c4fcaf3
      antirez authored
      GEOHASH, GEOPOS and GEODIST where declared as commands not accepting
      keys, so the Redis Cluster redirection did not worked.
      
      Close #2671.
      5c4fcaf3
  6. 09 Jul, 2015 1 commit
    • antirez's avatar
      GEOENCODE / GEODECODE commands removed. · b96af595
      antirez authored
      Rationale:
      
      1. The commands look like internals exposed without a real strong use
      case.
      2. Whatever there is an use case, the client would implement the
      commands client side instead of paying RTT just to use a simple to
      reimplement library.
      3. They add complexity to an otherwise quite straightforward API.
      
      So for now KILLED ;-)
      b96af595
  7. 29 Jun, 2015 3 commits
  8. 26 Jun, 2015 1 commit
  9. 24 Jun, 2015 2 commits
  10. 22 Jun, 2015 2 commits
    • antirez's avatar
      Geo: JSON features removed · b18c68aa
      antirez authored
      The command can only return data in the normal Redis protocol. It is up
      to the caller to translate to JSON if needed.
      b18c68aa
    • Matt Stancliff's avatar
      [In-Progress] Add Geo Commands · 7f4ac3d1
      Matt Stancliff authored
      Current todo:
        - replace functions in zset.{c,h} with a new unified Redis
          zset access API.
      
      Once we get the zset interface fixed, we can squash
      relevant commits in this branch and have one nice commit
      to merge into unstable.
      
      This commit adds:
        - Geo commands
        - Tests; runnable with: ./runtest --single unit/geo
        - Geo helpers in deps/geohash-int/
        - src/geo.{c,h} and src/geojson.{c,h} implementing geo commands
        - Updated build configurations to get everything working
        - TEMPORARY: src/zset.{c,h} implementing zset score and zset
          range reading without writing to client output buffers.
        - Modified linkage of one t_zset.c function for use in zset.c
      
      Conflicts:
      	src/Makefile
      	src/redis.c
      7f4ac3d1
  11. 05 May, 2015 1 commit
  12. 24 Mar, 2015 1 commit
    • antirez's avatar
      Cluster: redirection refactoring + handling of blocked clients. · 9b7f8b1c
      antirez authored
      There was a bug in Redis Cluster caused by clients blocked in a blocking
      list pop operation, for keys no longer handled by the instance, or
      in a condition where the cluster became down after the client blocked.
      
      A typical situation is:
      
      1) BLPOP <somekey> 0
      2) <somekey> hash slot is resharded to another master.
      
      The client will block forever int this case.
      
      A symmentrical non-cluster-specific bug happens when an instance is
      turned from master to slave. In that case it is more serious since this
      will desynchronize data between slaves and masters. This other bug was
      discovered as a side effect of thinking about the bug explained and
      fixed in this commit, but will be fixed in a separated commit.
      9b7f8b1c
  13. 22 Mar, 2015 1 commit
  14. 21 Mar, 2015 1 commit
  15. 20 Mar, 2015 2 commits
    • antirez's avatar
      Cluster: better cluster state transiction handling. · 25c0f5ac
      antirez authored
      Before we relied on the global cluster state to make sure all the hash
      slots are linked to some node, when getNodeByQuery() is called. So
      finding the hash slot unbound was checked with an assertion. However
      this is fragile. The cluster state is often updated in the
      clusterBeforeSleep() function, and not ASAP on state change, so it may
      happen to process clients with a cluster state that is 'ok' but yet
      certain hash slots set to NULL.
      
      With this commit the condition is also checked in getNodeByQuery() and
      reported with a identical error code of -CLUSTERDOWN but slightly
      different error message so that we have more debugging clue in the
      future.
      
      Root cause of issue #2288.
      25c0f5ac
    • antirez's avatar
      Cluster: move clusterBeforeSleep() call before unblocked clients processing. · 2ecb5edf
      antirez authored
      Related to issue #2288.
      2ecb5edf
  16. 11 Mar, 2015 2 commits
  17. 27 Feb, 2015 1 commit
    • antirez's avatar
      Hash: HSTRLEN (was HVSTRLEN) improved. · 4e54b85a
      antirez authored
      1. HVSTRLEN -> HSTRLEN. It's unlikely one needs the length of the key,
         not clear how the API would work (by value does not make sense) and
         there will be better names anyway.
      2. Default is to return 0 when field is missing.
      3. Default is to return 0 when key is missing.
      4. The implementation was slower than needed, and produced unnecessary COW.
      
      Related issue #2415.
      4e54b85a
  18. 21 Feb, 2015 1 commit
  19. 11 Feb, 2015 6 commits
  20. 03 Feb, 2015 1 commit
    • antirez's avatar
      Handle redis-check-rdb as a standalone program. · 7d1e1580
      antirez authored
      This also makes it backward compatible in the usage, but for the command
      name. However the old command name was less obvious so it is worth to
      break it probably.
      
      With the new setup the program main can perform argument parsing and
      everything else useful for an RDB check regardless of the Redis server
      itself.
      7d1e1580
  21. 28 Jan, 2015 1 commit
    • Matt Stancliff's avatar
      Convert check-dump to Redis check-rdb mode · 145473ac
      Matt Stancliff authored
      redis-check-dump is now named redis-check-rdb and it runs
      as a mode of redis-server instead of an independent binary.
      
      You can now use 'redis-server redis.conf --check-rdb' to check
      the RDB defined in redis.conf.  Using argument --check-rdb
      checks the RDB and exits.  We could potentially also allow
      the server to continue starting if the RDB check succeeds.
      
      This change also enables us to use RDB checking programatically
      from inside Redis for certain failure conditions.
      145473ac