1. 26 Jun, 2014 1 commit
    • antirez's avatar
      Test: hopefully more robust PSYNC test. · e7887e60
      antirez authored
      This is supposed to fix issue #1417, but we'll know if this is enough
      only after a couple of runs of the CI test without false positives.
      e7887e60
  2. 23 Jun, 2014 1 commit
  3. 05 Jun, 2014 1 commit
  4. 22 May, 2014 1 commit
  5. 29 Jul, 2013 1 commit
  6. 25 Jun, 2013 3 commits
  7. 19 Jun, 2013 1 commit
  8. 31 May, 2013 1 commit
  9. 30 May, 2013 2 commits
  10. 09 May, 2013 1 commit
  11. 08 May, 2013 2 commits
  12. 23 Apr, 2013 1 commit
    • antirez's avatar
      Test: fix RDB test checking file permissions. · c4656119
      antirez authored
      When the test is executed using the root account, setting the permission
      to 222 does not work as expected, as root can read files with 222
      permission.
      
      Now we skip the test if root is detected.
      
      This fixes issue #1034 and the duplicated #1040 issue.
      
      Thanks to Jan-Erik Rediger (@badboy on Github) for finding a way to reproduce the issue.
      c4656119
  13. 22 Apr, 2013 1 commit
  14. 13 Mar, 2013 2 commits
  15. 12 Mar, 2013 1 commit
  16. 23 Jan, 2013 1 commit
  17. 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
  18. 30 Apr, 2012 1 commit
  19. 29 Apr, 2012 1 commit
  20. 26 Apr, 2012 1 commit
  21. 17 Apr, 2012 1 commit
  22. 04 Apr, 2012 1 commit
  23. 30 Mar, 2012 1 commit
  24. 25 Mar, 2012 1 commit
  25. 23 Mar, 2012 2 commits
  26. 25 Jan, 2012 1 commit
  27. 12 Jan, 2012 1 commit
  28. 06 Jan, 2012 1 commit
  29. 10 Dec, 2011 1 commit
  30. 07 Dec, 2011 1 commit
  31. 17 Oct, 2011 1 commit
  32. 16 Sep, 2011 1 commit
  33. 11 Jul, 2011 2 commits