Feature Request to make Streams type more easy to use. (About CLAIM and ACK)
米加速
Hi, I am very exciting about the new Streams feature, but after trying to use it, I found it is not that easy to use. Here are some ideas that may be make it better.
- Can XPENDING return entries filtered by idle time?
- If I want to find some entries that expired, I have to check all the pending items, which is very expensive.
- Hope the XPENDING can return entries that exceeds a certain idle time.
- Can XCLAIM auto CLAIM entries by idle time?
- I have to send all the expired id to XCLAIM command, which is also very unfriendly. I think in many common cases, people only want to make the expired entry to be redelivered.
- Can XCLAIM change the id to newest one?
- And also, It is very unconvenient to use the XCLAIM mechanism, because every consumer must have a thread to check if there are new entries claimed to me.
- Why not add another option that claimed message can looks like a new message and the old one is gone?
- Can XACK support range ack?
- since XGROUPREAD will read items in order, so after a consumer completed a batch, the consumer can ack the items in range between the first and last id in one request.
- If I want to find some entries that expired, I have to check all the pending items, which is very expensive.
- Hope the XPENDING can return entries that exceeds a certain idle time.
- I have to send all the expired id to XCLAIM command, which is also very unfriendly. I think in many common cases, people only want to make the expired entry to be redelivered.
- And also, It is very unconvenient to use the XCLAIM mechanism, because every consumer must have a thread to check if there are new entries claimed to me.
- Why not add another option that claimed message can looks like a new message and the old one is gone?
- since XGROUPREAD will read items in order, so after a consumer completed a batch, the consumer can ack the items in range between the first and last id in one request.
Nick Farrell
Even better than modifying xclaim would be extending xreadgroup to include an idle setting, and if there are any pending messages which have been idle for more than this period, they are atomically claimed and returned. This would massively simplify the client logic and would actually decrease server load, due to the streamlined logic and less back-and-forthing.
I'm less sure about bulk ACKing of messages. An asynchronous client should not be adversely affected by sending acks, and it reduces the window for accidentally processing messages multiple times. But if you are processing large numbers of messages at a time, I can see why you may want to avoid ACKing each one. In fact, assuming consumer names are unique, you could safely use a command to truncate your pending queue rather than needing to provide a message ID argument.