- 12 Jun, 2018 5 commits
-
-
antirez authored
-
antirez authored
See issue #5006. The comment in the code was also wrong and was rectified as well.
-
Salvatore Sanfilippo authored
fix typo issue #5005
-
antirez authored
See issue #5005 comments.
-
Baoyi Chen authored
fix [#5005](https://github.com/antirez/redis/issues/5005)
-
- 11 Jun, 2018 11 commits
-
-
antirez authored
A user with many connections (10 thousand) on a single Redis server reports in issue #4983 that sometimes Redis is idle becuase at the same time many clients need to resize their query buffer according to the old policy. It looks like this was created by the fact that we allow the query buffer to grow without problems to a size up to PROTO_MBULK_BIG_ARG normally, but when the client is idle we immediately are more strict, and a query buffer greater than 1024 bytes is already enough to trigger the resize. So for instance if most of the clients stop at the same time this issue should be easily triggered. This behavior actually looks odd, and there should be only a clear limit after we say, let's look at this query buffer to check if it's time to resize it. This commit puts the limit at PROTO_MBULK_BIG_ARG, and the check is performed both if compared to the peak usage the current usage is too big, or if the client is idle. Then when the check is performed, to waste just a few kbytes is considered enough to proceed with the resize. This should fix the issue.
-
antirez authored
-
antirez authored
We unblocked the client too early, when the group name object was no longer valid in client->bpop, so propagating XCLAIM later in streamPropagateXCLAIM() deferenced a field already set to NULL.
-
Salvatore Sanfilippo authored
fix integer case error
-
Salvatore Sanfilippo authored
fix stream config typo
-
Salvatore Sanfilippo authored
Streams: lookupKey[Read->Write]OrReply in xdel and xtrim
-
Salvatore Sanfilippo authored
HW_PHYSMEM typo in preprocessor condition
-
Salvatore Sanfilippo authored
Streams: checkType for xread & xinfo
-
Salvatore Sanfilippo authored
Abort in XGROUP if the key is not a stream
-
antirez authored
Removing the fix about 50% of the times the test will not be able to pass cleanly. It's very hard to write a test that will always fail, or actually, it is possible but then it's likely that it will consistently pass if we change some random bit, so better to use randomization here.
-
antirez authored
-
- 10 Jun, 2018 3 commits
-
-
zhaozhao.zz authored
-
zhaozhao.zz authored
-
michael-grunder authored
-
- 09 Jun, 2018 1 commit
-
-
shenlongxing authored
-
- 08 Jun, 2018 5 commits
-
-
Salvatore Sanfilippo authored
Zset int problem
-
Salvatore Sanfilippo authored
adjust position of _dictNextPower in dictExpand
-
Salvatore Sanfilippo authored
RDB: expand dict if needed when rdb load object
-
antirez authored
-
antirez authored
-
- 07 Jun, 2018 9 commits
-
-
antirez authored
-
antirez authored
-
Salvatore Sanfilippo authored
Return early in XPENDING if sent a nonexistent consumer group.
-
shenlongxing authored
-
antirez authored
-
antirez 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.
-
- 06 Jun, 2018 2 commits
-
-
shenlongxing authored
-
antirez authored
Close #4989.
-
- 05 Jun, 2018 2 commits
- 04 Jun, 2018 2 commits
-
-
antirez authored
-
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.
-