Commit Graph

209 Commits

Author SHA1 Message Date
James Rouzier 3ccdcbc088 Fix start and end key initialize 2019-04-11 12:19:02 -04:00
Salvatore Sanfilippo 2537b2140f
Merge pull request #5787 from soloestoy/bugfix-xgroup-create-with-mkstream
Streams: checkType before XGROUP CREATE
2019-03-13 12:34:29 +01:00
Steve Webster dfcb227b50 Only increment delivery count if JUSTID option is omitted 2019-03-12 20:27:53 +00:00
Steve Webster f1e7df4b7c Increment delivery counter on XCLAIM unless RETRYCOUNT specified
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
2019-03-08 17:09:11 +00:00
zhaozhao.zz 645d44d545 Streams: checkType before XGROUP CREATE
Fix issue #5785, in case create group on a key is not stream.
2019-01-16 19:19:14 +08:00
antirez 8a0391fbc9 RESP3: t_stream.c updated. 2019-01-09 17:00:29 +01:00
antirez 2bd6802fa1 Stream: fix XREADGROUP history reading of deleted messages.
This commit fixes #5570. It is a similar bug to one fixed a few weeks
ago and is due to the range API to be called with NULL as "end ID"
parameter instead of repeating again the start ID, to be sure that we
selectively issue the entry with a given ID, or we get zero returned
(and we know we should emit a NULL reply).
2018-11-19 17:00:34 +01:00
antirez 29251f58e2 Streams: fix XREADGROUP history reading when CG last_id is low.
This fixes the issue reported in #5570.
This was fixed the hard way, that is, propagating more information to
the lower level API about this being a request to read just the history,
so that the code is simpler and less likely to regress.
2018-11-19 16:41:27 +01:00
antirez 3830ef2483 t_stream.c comment resized to 80 cols. 2018-11-19 16:26:02 +01:00
antirez 6ba50784b5 Fix XCLAIM missing entry bug.
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.
2018-11-05 13:17:32 +01:00
antirez 514bbdd670 Merge branch 'unstable' of github.com:/antirez/redis into unstable 2018-11-05 13:07:14 +01:00
antirez e7c579e1fe Improve streamReplyWithRange() top comment. 2018-11-05 13:06:01 +01:00
michael-grunder 5fa41e0c84 Use typedef'd mstime_t instead of time_t
This fixes an overflow on 32-bit systems.
2018-11-03 15:13:28 -07:00
Guy Korland 48d8b3d8ac
Fix some typos 2018-10-31 17:33:53 +02:00
antirez f5494b1862 Add command fingerprint comment for XSETID. 2018-10-25 13:08:48 +02:00
antirez 998001fbf2 Merge branch 'unstable' of github.com:/antirez/redis into unstable 2018-10-25 11:50:15 +02:00
Salvatore Sanfilippo 12d5be1bf2
Merge pull request #5459 from itamarhaber/xpending_count_underflow
A fix to XPENDING's count underflow
2018-10-25 11:50:04 +02:00
antirez 6e11ef30e0 Fix XRANGE COUNT option for value of 0. 2018-10-25 11:36:24 +02:00
antirez f06e8c331c Fix typo in streamReplyWithRange() top comment. 2018-10-24 16:28:44 +02:00
Itamar Haber edeaf85cab Plugs a potential underflow 2018-10-17 19:33:11 +03:00
antirez 144832ee67 Streams: use bulk replies instead of status replies.
They play better with Lua scripting, otherwise Lua will see status
replies as "ok" = "string" which is very odd, and actually as @oranagra
reasoned in issue #5456 in the rest of the Redis code base there was no
such concern as saving a few bytes when the protocol is emitted.
2018-10-17 17:21:09 +02:00
Itamar Haber acb3b55280 Corrects inline documentation of syntax 2018-10-17 16:13:55 +03:00
antirez fdb575993f Fix conditional in XGROUP. 2018-10-17 13:00:35 +02:00
antirez 492fd5c011 Fix XGROUP CREATE MKSTREAM handling of . 2018-10-17 12:10:52 +02:00
antirez 2e3d403349 Process MKSTREAM option of XGROUP CREATE at a later time.
This avoids issues with having to replicate a command that produced
errors.
2018-10-17 12:04:06 +02:00
antirez cb27dd1a68 XGROUP CREATE: MKSTREAM option for automatic stream creation. 2018-10-17 11:27:27 +02:00
antirez ea78a1db32 XSETID: accept IDs based on last entry.
Related to #5426.
2018-10-16 16:46:17 +02:00
antirez e3446fea9e Streams: XSTREAM SETID -> XSETID.
Keep vanilla stream commands at toplevel, see #5426.
2018-10-16 13:17:14 +02:00
Salvatore Sanfilippo af09df08d7
Merge pull request #5426 from soloestoy/feature-xstream
Bugfix data inconsistency after aof rewrite, and add XSTREAM command.
2018-10-16 13:10:36 +02:00
antirez 3640e029d6 Make comment about nack->consumer test for minidle more obvious.
Related to #5437.
2018-10-15 12:01:17 +02:00
antirez 0b1784b188 Streams: use propagate_last_id itself as streamPropagateGroupID trigger.
Avoid storing the dirty value. See #5437.
2018-10-15 11:52:24 +02:00
antirez 820b1e6e7d Streams: better naming: lastid_updated -> propagate_last_id.
See #5437 but also I updated a previous usage of the same var name.
2018-10-15 11:50:18 +02:00
zhaozhao.zz 5cc0522303 Streams: panic if streamID invalid after check, should not be possible. 2018-10-11 21:46:47 +08:00
zhaozhao.zz 08ae522ff9 Streams: propagate lastid in XCLAIM when it has effect 2018-10-11 21:44:20 +08:00
zhaozhao.zz 183ef7ae9b Streams: XCLAIM ignore minidle if NACK is created by FORCE
Because the NACK->consumer is NULL, if idletime < minidle
the NACK does not belong to any consumer, then redis will crash
in XPENDING.
2018-10-11 21:20:49 +08:00
zhaozhao.zz 4dc48a0d11 Streams: bugfix XCLAIM should propagate group name not consumer name 2018-10-11 21:12:09 +08:00
antirez c9d9ae7baa Fix propagation of consumer groups last ID.
Issue #5433.
2018-10-10 12:51:02 +02:00
zhaozhao.zz 480e299436 Streams: rewrite id in XSTREAM CREATE * 2018-10-09 16:22:30 +08:00
zhaozhao.zz ec511fa709 Streams: add a new command XTREAM
XSTREAM CREATE <key> <id or *> -- Create a new empty stream.
XSTREAM SETID <key> <id or $>  -- Set the current stream ID.
2018-10-09 13:11:04 +08:00
antirez 3e78344d87 Refactoring of XADD / XTRIM MAXLEN rewriting.
See #5141.
2018-10-08 12:05:22 +02:00
Salvatore Sanfilippo e5f1de1448
Merge pull request #5141 from soloestoy/fix-xtrim-inconsistency
Fix XTRIM and XADD with MAXLEN inconsistency
2018-10-08 12:00:00 +02:00
antirez 68c0e6e331 xclaimCommand(): fix comment typos. 2018-10-04 17:34:06 +02:00
antirez 32e0d2376f streamAppendItem(): Update the radix tree pointer only if changed. 2018-10-02 19:45:33 +02:00
antirez c7c3b23787 streamIteratorRemoveEntry(): set back lp only if pointer changed.
Most of the times the pointer will remain the same since integers of
similar size don't take more space in listpacks.

Related to #5210.
2018-10-02 16:20:40 +02:00
Salvatore Sanfilippo 9fe7cd8f14
Merge pull request #5210 from soloestoy/raxinsert-in-xdel
Streams: update listpack with new pointer in XDEL
2018-10-02 16:18:55 +02:00
antirez 9e0e5ccbf4 Fix XINFO comment for consistency. 2018-10-01 11:38:58 +02:00
Guy Korland 8b87876094
add missing argument to function doc 2018-09-21 02:46:31 +03:00
Sascha Roland c1e9186f06 #5299 Fix blocking XREAD for streams that ran dry
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.
2018-09-04 13:13:36 +02:00
zhaozhao.zz a3a1460525 Streams: update listpack with new pointer in XDEL 2018-08-04 01:06:53 +08:00
Salvatore Sanfilippo 39c70e728b
Merge pull request #5146 from 0xtonyxia/fix-xclaim-id-parse
Streams: ID of xclaim command should start from the sixth argument.
2018-08-03 13:45:27 +02:00