- 17 Jul, 2018 3 commits
- 16 Jul, 2018 5 commits
-
-
zhaozhao.zz authored
-
antirez authored
-
antirez authored
Related to #5129.
-
zhaozhao.zz authored
-
zhaozhao.zz authored
-
- 14 Jul, 2018 1 commit
-
-
dejun.xdj authored
-
- 12 Jul, 2018 2 commits
-
-
antirez authored
We don't want to increment the deliveries here, because the sysadmin reset the consumer group so the desire is likely to restart processing, and having the PEL polluted with old information is not useful but probably confusing. Related to #5111.
-
antirez authored
We don't really need to distinguish between the case the consumer is the same or is a different one.
-
- 10 Jul, 2018 3 commits
-
-
antirez authored
-
antirez authored
To simplify the semantics of blocking for a group, this commit changes the implementation to better match the description we provide of conusmer groups: blocking for > will make the consumer waiting for new elements in the group. However blocking for any other ID will always serve the local history of the consumer. However it must be noted that the > ID is actually an alias for the special ID ms/seq of UINT64_MAX,UINT64_MAX.
-
dejun.xdj authored
For issue #5111.
-
- 09 Jul, 2018 1 commit
-
-
dejun.xdj authored
Save NOACK option into client.blockingState structure.
-
- 03 Jul, 2018 1 commit
-
-
Jack Drogon authored
-
- 02 Jul, 2018 1 commit
-
-
antirez authored
-
- 27 Jun, 2018 1 commit
-
-
Mustafa Paltun authored
-
- 18 Jun, 2018 1 commit
-
-
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.
-
- 17 Jun, 2018 1 commit
-
-
antirez authored
-
- 13 Jun, 2018 4 commits
-
-
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().
-
antirez authored
-
antirez authored
-
Baoyi Chen authored
fix [#5005](https://github.com/antirez/redis/issues/5005)
-
- 12 Jun, 2018 16 commits
-
-
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().
-
antirez authored
-
Itamar Haber authored
-
antirez authored
-
antirez authored
See issue #5006. The comment in the code was also wrong and was rectified as well.
-
antirez authored
See issue #5005 comments.
-
zhaozhao.zz authored
-
zhaozhao.zz authored
-
michael-grunder authored
-
antirez authored
-
antirez authored
-
antirez authored
Also add the concept of size/items limit, instead of just having as limit the number of bytes.
-
michael-grunder authored
-
antirez authored
See issue #5006. The comment in the code was also wrong and was rectified as well.
-
antirez authored
See issue #5005 comments.
-
Baoyi Chen authored
fix [#5005](https://github.com/antirez/redis/issues/5005)
-