1. 12 Mar, 2019 1 commit
  2. 08 Mar, 2019 1 commit
    • Steve Webster's avatar
      Increment delivery counter on XCLAIM unless RETRYCOUNT specified · f1e7df4b
      Steve Webster authored
      The XCLAIM docs state the XCLAIM increments the delivery counter for
      messages. This PR makes the code match the documentation - which seems
      like the desired behaviour - whilst still allowing RETRYCOUNT to be
      specified manually.
      
      My understanding of the way streamPropagateXCLAIM() works is that this
      change will safely propagate to replicas since retry count is pulled
      directly from the streamNACK struct.
      
      Fixes #5194
      f1e7df4b
  3. 16 Jan, 2019 1 commit
  4. 09 Jan, 2019 1 commit
  5. 19 Nov, 2018 3 commits
  6. 05 Nov, 2018 2 commits
    • antirez's avatar
      Fix XCLAIM missing entry bug. · 6ba50784
      antirez authored
      This bug had a double effect:
      
      1. Sometimes entries may not be emitted, producing broken protocol where
      the array length was greater than the emitted entires, blocking the
      client waiting for more data.
      
      2. Some other time the right entry was claimed, but a wrong entry was
      returned to the client.
      
      This fix should correct both the instances.
      6ba50784
    • antirez's avatar
      Improve streamReplyWithRange() top comment. · e7c579e1
      antirez authored
      e7c579e1
  7. 03 Nov, 2018 1 commit
  8. 31 Oct, 2018 1 commit
  9. 25 Oct, 2018 2 commits
  10. 24 Oct, 2018 1 commit
  11. 17 Oct, 2018 7 commits
  12. 16 Oct, 2018 2 commits
  13. 15 Oct, 2018 3 commits
  14. 11 Oct, 2018 4 commits
  15. 10 Oct, 2018 1 commit
  16. 09 Oct, 2018 2 commits
  17. 08 Oct, 2018 1 commit
  18. 04 Oct, 2018 1 commit
  19. 02 Oct, 2018 2 commits
  20. 01 Oct, 2018 1 commit
  21. 20 Sep, 2018 1 commit
  22. 04 Sep, 2018 1 commit
    • Sascha Roland's avatar
      #5299 Fix blocking XREAD for streams that ran dry · c1e9186f
      Sascha Roland authored
      The conclusion, that a xread request can be answered syncronously in
      case that the stream's last_id is larger than the passed last-received-id
      parameter, assumes, that there must be entries present, which could be
      returned immediately.
      This assumption fails for empty streams that actually contained some
      entries which got removed by xdel, ... .
      
      As result, the client is answered synchronously with an empty result,
      instead of blocking for new entries to arrive.
      An additional check for a non-empty stream is required.
      c1e9186f