1. 04 Oct, 2018 1 commit
  2. 02 Oct, 2018 2 commits
  3. 01 Oct, 2018 1 commit
  4. 20 Sep, 2018 1 commit
  5. 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
  6. 03 Aug, 2018 2 commits
  7. 01 Aug, 2018 4 commits
  8. 31 Jul, 2018 1 commit
  9. 30 Jul, 2018 2 commits
  10. 24 Jul, 2018 2 commits
  11. 22 Jul, 2018 1 commit
  12. 19 Jul, 2018 1 commit
  13. 17 Jul, 2018 3 commits
  14. 16 Jul, 2018 5 commits
  15. 14 Jul, 2018 1 commit
  16. 12 Jul, 2018 2 commits
  17. 10 Jul, 2018 3 commits
  18. 09 Jul, 2018 1 commit
  19. 03 Jul, 2018 1 commit
  20. 02 Jul, 2018 1 commit
  21. 27 Jun, 2018 1 commit
  22. 18 Jun, 2018 1 commit
    • antirez's avatar
      Streams: Change XADD MAXLEN handling of values <= 0. · 62f9ac6f
      antirez authored
      Now a MAXLEN of 0 really does what it means: it will create a zero
      entries stream. This is useful in order to make sure that the behavior
      is identical to XTRIM, that must be able to reduce the stream to zero
      elements when MAXLEN is given.
      
      Also now MAXLEN with a count < 0 will return an error.
      62f9ac6f
  23. 17 Jun, 2018 1 commit
  24. 12 Jun, 2018 1 commit
    • antirez's avatar
      Streams: generate a few additional events. · 6b8a24a6
      antirez authored
      Currently it does not look it's sensible to generate events for streams
      consumer groups modification, being them metadata, however at least for
      key-level events, like the creation or removal of a consumer group, I
      added a few events here and there. Later we can evaluate if it makes
      sense to add more. From the POV instead of WAIT (in Redis transaciton)
      and signaling the key as modified, it looks like that the transaction
      should not fail when a stream is modified, so no calls are made in
      consumer groups related functions to signalModifiedKey().
      6b8a24a6