1. 30 Oct, 2015 12 commits
    • 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
      fdc8e0bd
    • 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
      f0434cae
    • 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
  2. 27 Oct, 2015 1 commit
  3. 15 Oct, 2015 9 commits
  4. 09 Oct, 2015 4 commits
  5. 06 Oct, 2015 2 commits
  6. 01 Oct, 2015 9 commits
  7. 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
  8. 29 Sep, 2015 1 commit
  9. 15 Sep, 2015 1 commit
    • antirez's avatar
      Test: fix false positive in HSTRLEN test. · 846da5b2
      antirez authored
      HINCRBY* tests later used the value "tmp" that was sometimes generated
      by the random key generation function. The result was ovewriting what
      Tcl expected to be inside Redis with another value, causing the next
      HSTRLEN test to fail.
      846da5b2