1. 09 Nov, 2015 3 commits
    • antirez's avatar
      Use clientHasPendingReplies() in flushSlavesOutputBuffers() · a26d5ca4
      antirez authored
      The old version only flushed data to slaves if there were strings
      pending in the client->reply list. Now also static buffers are flushed.
      Does not help to free memory (which is the only use we have right now in
      the fuction), but is more correct conceptually, and may be used in
      other contexts.
      a26d5ca4
    • antirez's avatar
      Scripting: fix redis.call() error reporting. · a89a3543
      antirez authored
      Arguments arity and arguments type error of redis.call() were not
      reported correctly to Lua, so the command acted in this regard like
      redis.pcall(), but just for two commands. Redis.call() should always
      raise errors instead.
      a89a3543
    • antirez's avatar
      Fix error reply in subscribed Pub/Sub mode. · 37109d8a
      antirez authored
      PING is now a valid command to issue in this context.
      37109d8a
  2. 05 Nov, 2015 2 commits
  3. 30 Oct, 2015 11 commits
    • antirez's avatar
      Dependencies updated. · 9639f9c0
      antirez authored
      9639f9c0
    • antirez's avatar
      More reliable DEBUG loadaof. · 4fe431c7
      antirez authored
      Make sure to flush the AOF output buffers before reloading.
      Result: less false timing related false positives on AOF tests.
      4fe431c7
    • antirez's avatar
      Scripting: ability to turn on Lua commands style replication globally. · 8695d960
      antirez authored
      Currently this feature is only accessible via DEBUG for testing, since
      otherwise depending on the instance configuration a given script works
      or is broken, which is against the Redis philosophy.
      8695d960
    • antirez's avatar
    • antirez's avatar
      Fix call() FORCE_REPL/AOF flags setting. · e9d2329c
      antirez authored
      This commit also inverts two stanzas of the code just becuase they are
      more logical like that, not because currently it makes any difference.
      e9d2329c
    • antirez's avatar
      Lua script selective replication fixes. · dfe7f797
      antirez authored
      dfe7f797
    • antirez's avatar
      Lua script selective replication WIP. · a1d1ca14
      antirez authored
      a1d1ca14
    • antirez's avatar
      Scripting: single commands replication mode implemented. · cbbfaf6a
      antirez authored
      By calling redis.replicate_commands(), the scripting engine of Redis
      switches to commands replication instead of replicating whole scripts.
      This is useful when the script execution is costly but only results in a
      few writes performed to the dataset.
      
      Morover, in this mode, it is possible to call functions with side
      effects freely, since the script execution does not need to be
      deterministic: anyway we'll capture the outcome from the point of view
      of changes to the dataset.
      
      In this mode math.random() returns different sequences at every call.
      
      If redis.replicate_commnads() is not called before any other write, the
      command returns false and sticks to whole scripts replication instead.
      cbbfaf6a
    • antirez's avatar
    • antirez's avatar
      0259da8c
    • antirez's avatar
      CLIENT REPLY command implemented: ON, OFF and SKIP modes. · de4d6caf
      antirez authored
      Sometimes it can be useful for clients to completely disable replies
      from the Redis server. For example when the client sends fire and forget
      commands or performs a mass loading of data, or in caching contexts
      where new data is streamed constantly. In such contexts to use server
      time and bandwidth in order to send back replies to clients, which are
      going to be ignored, is a shame.
      
      Multiple mechanisms are possible to implement such a feature. For
      example it could be a feature of MULTI/EXEC, or a command prefix
      such as "NOREPLY SADD myset foo", or a different mechanism that allows
      to switch on/off requests using the CLIENT command.
      
      The MULTI/EXEC approach has the problem that transactions are not
      strictly part of the no-reply semantics, and if we want to insert a lot
      of data in a bulk way, creating a huge MULTI/EXEC transaction in the
      server memory is bad.
      
      The prefix is the best in this specific use case since it does not allow
      desynchronizations, and is pretty clear semantically. However Redis
      internals and client libraries are not prepared to handle this
      currently.
      
      So the implementation uses the CLIENT command, providing a new REPLY
      subcommand with three options:
      
          CLIENT REPLY OFF disables the replies, and does not reply itself.
          CLIENT REPLY ON re-enables the replies, replying +OK.
          CLIENT REPLY SKIP only discards the reply of the next command, and
                            like OFF does not reply anything itself.
      
      The reason to add the SKIP command is that it allows to have an easy
      way to send conceptually "single" commands that don't need a reply
      as the sum of two pipelined commands:
      
          CLIENT REPLY SKIP
          SET key value
      
      Note that CLIENT REPLY ON replies with +OK so it should be used when
      sending multiple commands that don't need a reply. However since it
      replies with +OK the client can check that the connection is still
      active and all the previous commands were received.
      
      This is currently just into Redis "unstable" so the proposal can be
      modified or abandoned based on users inputs.
      de4d6caf
  4. 15 Oct, 2015 6 commits
  5. 09 Oct, 2015 1 commit
    • antirez's avatar
      Fix extractLongLatOrReply() sanity check conditionals. · 77df3b06
      antirez authored
      the check for lat/long valid ranges were performed inside the for loop,
      two times instead of one, and the first time when the second element of
      the array, xy[1], was yet not populated. This resulted into issue #2799.
      
      Close issue #2799.
      77df3b06
  6. 06 Oct, 2015 1 commit
  7. 01 Oct, 2015 9 commits
  8. 30 Sep, 2015 1 commit
    • antirez's avatar
      redis-cli pipe mode: don't stay in the write loop forever. · 0f81f83e
      antirez authored
      The code was broken and resulted in redis-cli --pipe to, most of the
      times, writing everything received in the standard input to the Redis
      connection socket without ever reading back the replies, until all the
      content to write was written.
      
      This means that Redis had to accumulate all the output in the output
      buffers of the client, consuming a lot of memory.
      
      Fixed thanks to the original report of anomalies in the behavior
      provided by Twitter user @fsaintjacques.
      0f81f83e
  9. 14 Sep, 2015 3 commits
    • antirez's avatar
      GEORADIUS: Don't report duplicates when radius is huge. · 3c23b5ff
      antirez authored
      Georadius works by computing the center + neighbors squares covering all
      the area of the specified position and radius. Then a distance filter is
      used to remove elements which are actually outside the range.
      
      When a huge radius is used, like 5000 km or more, adjacent neighbors may
      collide and be the same, leading to the reporting of the same element
      multiple times. This only happens in the edge case of huge radius but is
      not ideal.
      
      A robust but slow solution would involve qsorting the range to remove
      all the duplicates. However since the collisions are only in adjacent
      boxes, for the way they are ordered in the code, it is much faster to
      just check if the current box is the same as the previous one processed.
      
      This commit adds a regression test for the bug.
      
      Fixes #2767.
      3c23b5ff
    • antirez's avatar
      MOVE re-add TTL check fixed. · 4fec5ee1
      antirez authored
      getExpire() returns -1 when no expire exists.
      
      Related to #2765.
      4fec5ee1
    • antirez's avatar
      MOVE now can move TTL metadata as well. · f529a01c
      antirez authored
      MOVE was not able to move the TTL: when a key was moved into a different
      database number, it became persistent like if PERSIST was used.
      
      In some incredible way (I guess almost nobody uses Redis MOVE) this bug
      remained unnoticed inside Redis internals for many years.
      Finally Andy Grunwald discovered it and opened an issue.
      
      This commit fixes the bug and adds a regression test.
      
      Close #2765.
      f529a01c
  10. 08 Sep, 2015 1 commit
  11. 07 Sep, 2015 2 commits
    • antirez's avatar
      Undo slaves state change on failed rdbSaveToSlavesSockets(). · 8e555374
      antirez authored
      As Oran Agra suggested, in startBgsaveForReplication() when the BGSAVE
      attempt returns an error, we scan the list of slaves in order to remove
      them since there is no way to serve them currently.
      
      However we check for the replication state BGSAVE_START, which was
      modified by rdbSaveToSlaveSockets() before forking(). So when fork fails
      the state of slaves remain BGSAVE_END and no cleanup is performed.
      
      This commit fixes the problem by making rdbSaveToSlavesSockets() able to
      undo the state change on fork failure.
      8e555374
    • ubuntu's avatar
      SCAN iter parsing changed from atoi to chartoull · 11381b09
      ubuntu authored
      11381b09