1. 22 Oct, 2012 1 commit
    • antirez's avatar
      Differentiate SCRIPT KILL error replies. · acfe3675
      antirez authored
      When calling SCRIPT KILL currently you can get two errors:
      
      * No script in timeout (busy) state.
      * The script already performed a write.
      
      It is useful to be able to distinguish the two errors, but right now both
      start with "ERR" prefix, so string matching (that is fragile) must be used.
      
      This commit introduces two different prefixes.
      
      -NOTBUSY and -UNKILLABLE respectively to reply with an error when no
      script is busy at the moment, and when the script already executed a
      write operation and can not be killed.
      acfe3675
  2. 01 Oct, 2012 1 commit
  3. 28 Sep, 2012 1 commit
    • antirez's avatar
      Scripting: redis.NIL to return nil bulk replies. · 6dd1693c
      antirez authored
      Lua arrays can't contain nil elements (see
      http://www.lua.org/pil/19.1.html for more information), so Lua scripts
      were not able to return a multi-bulk reply containing nil bulk
      elements inside.
      
      This commit introduces a special conversion: a table with just
      a "nilbulk" field set to a boolean value is converted by Redis as a nil
      bulk reply, but at the same time for Lua this type is not a "nil" so can
      be used inside Lua arrays.
      
      This type is also assigned to redis.NIL, so the following two forms
      are equivalent and will be able to return a nil bulk reply as second
      element of a three elements array:
      
          EVAL "return {1,redis.NIL,3}" 0
          EVAL "return {1,{nilbulk=true},3}" 0
      
      The result in redis-cli will be:
      
          1) (integer) 1
          2) (nil)
          3) (integer) 3
      6dd1693c
  4. 17 Sep, 2012 1 commit
    • antirez's avatar
      A reimplementation of blocking operation internals. · 7eb850ef
      antirez authored
      Redis provides support for blocking operations such as BLPOP or BRPOP.
      This operations are identical to normal LPOP and RPOP operations as long
      as there are elements in the target list, but if the list is empty they
      block waiting for new data to arrive to the list.
      
      All the clients blocked waiting for th same list are served in a FIFO
      way, so the first that blocked is the first to be served when there is
      more data pushed by another client into the list.
      
      The previous implementation of blocking operations was conceived to
      serve clients in the context of push operations. For for instance:
      
      1) There is a client "A" blocked on list "foo".
      2) The client "B" performs `LPUSH foo somevalue`.
      3) The client "A" is served in the context of the "B" LPUSH,
      synchronously.
      
      Processing things in a synchronous way was useful as if "A" pushes a
      value that is served by "B", from the point of view of the database is a
      NOP (no operation) thing, that is, nothing is replicated, nothing is
      written in the AOF file, and so forth.
      
      However later we implemented two things:
      
      1) Variadic LPUSH that could add multiple values to a list in the
      context of a single call.
      2) BRPOPLPUSH that was a version of BRPOP that also provided a "PUSH"
      side effect when receiving data.
      
      This forced us to make the synchronous implementation more complex. If
      client "B" is waiting for data, and "A" pushes three elemnents in a
      single call, we needed to propagate an LPUSH with a missing argument
      in the AOF and replication link. We also needed to make sure to
      replicate the LPUSH side of BRPOPLPUSH, but only if in turn did not
      happened to serve another blocking client into another list ;)
      
      This were complex but with a few of mutually recursive functions
      everything worked as expected... until one day we introduced scripting
      in Redis.
      
      Scripting + synchronous blocking operations = Issue #614.
      
      Basically you can't "rewrite" a script to have just a partial effect on
      the replicas and AOF file if the script happened to serve a few blocked
      clients.
      
      The solution to all this problems, implemented by this commit, is to
      change the way we serve blocked clients. Instead of serving the blocked
      clients synchronously, in the context of the command performing the PUSH
      operation, it is now an asynchronous and iterative process:
      
      1) If a key that has clients blocked waiting for data is the subject of
      a list push operation, We simply mark keys as "ready" and put it into a
      queue.
      2) Every command pushing stuff on lists, as a variadic LPUSH, a script,
      or whatever it is, is replicated verbatim without any rewriting.
      3) Every time a Redis command, a MULTI/EXEC block, or a script,
      completed its execution, we run the list of keys ready to serve blocked
      clients (as more data arrived), and process this list serving the
      blocked clients.
      4) As a result of "3" maybe more keys are ready again for other clients
      (as a result of BRPOPLPUSH we may have push operations), so we iterate
      back to step "3" if it's needed.
      
      The new code has a much simpler semantics, and a simpler to understand
      implementation, with the disadvantage of not being able to "optmize out"
      a PUSH+BPOP as a No OP.
      
      This commit will be tested with care before the final merge, more tests
      will be added likely.
      7eb850ef
  5. 04 Sep, 2012 1 commit
    • antirez's avatar
      Scripting: Force SORT BY constant determinism inside SORT itself. · 36741b2c
      antirez authored
      SORT is able to return (faster than when ordering) unordered output if
      the "BY" clause is used with a constant value. However we try to play
      well with scripting requirements of determinism providing always sorted
      outputs when SORT (and other similar commands) are called by Lua
      scripts.
      
      However we used the general mechanism in place in scripting in order to
      reorder SORT output, that is, if the command has the "S" flag set, the
      Lua scripting engine will take an additional step when converting a
      multi bulk reply to Lua value, calling a Lua sorting function.
      
      This is suboptimal as we can do it faster inside SORT itself.
      This is also broken as issue #545 shows us: basically when SORT is used
      with a constant BY, and additionally also GET is used, the Lua scripting
      engine was trying to order the output as a flat array, while it was
      actually a list of key-value pairs.
      
      What we do know is to recognized if the caller of SORT is the Lua client
      (since we can check this using the REDIS_LUA_CLIENT flag). If so, and if
      a "don't sort" condition is triggered by the BY option with a constant
      string, we force the lexicographical sorting.
      
      This commit fixes this bug and improves the performance, and at the same
      time simplifies the implementation. This does not mean I'm smart today,
      it means I was stupid when I committed the original implementation ;)
      36741b2c
  6. 31 Aug, 2012 1 commit
  7. 02 Jun, 2012 1 commit
    • antirez's avatar
      EVAL replication test: less false positives. · 80e808b6
      antirez authored
      wait_for_condition is now used instead of the usual "after 1000" (that
      is the way to sleep in Tcl). This should avoid to find the replica in
      a state where it is loading the RDB in memory, returning -LOADING error.
      
      This test used to fail when running the test over valgrind, due to the
      added latencies.
      80e808b6
  8. 26 Apr, 2012 1 commit
  9. 19 Apr, 2012 1 commit
  10. 18 Apr, 2012 1 commit
  11. 13 Apr, 2012 3 commits
  12. 28 Mar, 2012 1 commit
  13. 01 Feb, 2012 1 commit
  14. 31 Oct, 2011 1 commit
  15. 25 Oct, 2011 2 commits
  16. 20 Oct, 2011 1 commit
  17. 27 Sep, 2011 1 commit
  18. 15 Jul, 2011 2 commits
  19. 25 May, 2011 1 commit