- 10 Jul, 2018 2 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.
-
- 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
-
- 12 Jun, 2018 7 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.
-
Baoyi Chen authored
fix [#5005](https://github.com/antirez/redis/issues/5005)
-
- 10 Jun, 2018 3 commits
-
-
zhaozhao.zz authored
-
zhaozhao.zz authored
-
michael-grunder authored
-
- 07 Jun, 2018 3 commits
- 06 Jun, 2018 1 commit
-
-
antirez authored
Close #4989.
-
- 05 Jun, 2018 1 commit
-
-
antirez authored
As observed by Michael Grunder this usage while practical is inconsistent because for instance it does not work against a key called HELP. Removed.
-
- 04 Jun, 2018 2 commits
-
-
antirez authored
Now that we have SETID, the inetrnals of consumer groups should be able to handle the case of the same message delivered multiple times just as a side effect of calling XREADGROUP. Normally this should never happen but if the admin manually "XGROUP SETID mykey mygroup 0", messages will get re-delivered to clients waiting for the ">" special ID. The consumer groups internals were not able to handle the case of a message re-delivered in this circumstances that was already assigned to another owner.
-
antirez authored
-
- 03 Jun, 2018 1 commit
-
-
michael-grunder authored
-
- 25 May, 2018 5 commits
-
-
antirez authored
-
zhaozhao.zz authored
-
antirez authored
-
antirez authored
-
antirez authored
-
- 19 Apr, 2018 2 commits
- 18 Apr, 2018 1 commit
-
-
antirez authored
-
- 17 Apr, 2018 2 commits
- 10 Apr, 2018 3 commits
- 21 Mar, 2018 1 commit
-
-
charsyam authored
-
- 20 Mar, 2018 1 commit
-
-
antirez authored
This should be more than enough, even if in case of partial IDs that are not found, we send all the IDs to the slave/AOF, but this is definitely a corner case without bad effects if not some wasted space.
-