If I execute the command for Key: numbers, group: evens and consumer: C:
xpending numbers evens - + 100 C
then idle time for the Consumer is being reset:
xinfo consumers numbers evens. This should not happen as this creates issue in implementing the logic for Claiming the messages. When I am trying to Claim messages from PEL of another consumer and trying to allocate to C it puts the impression as if C just got idle because its idle time is reset.
Notice the idle time(5811) versus last delivered message to C.
Details: 127.0.0.1:6379> xpending numbers evens - + 100 C 1) 1) "1562748542611-0" 2) "C" 3) (integer) 1837620 4) (integer) 1 2) 1) "1562750561986-0" 2) "C" 3) (integer) 1180716 4) (integer) 1
127.0.0.1:6379> xinfo consumers numbers evens 1) 1) "name" 2) "A" 3) "pending" 4) (integer) 0 5) "idle" 6) (integer) 3844752 2) 1) "name" 2) "C" 3) "pending" 4) (integer) 2 5) "idle" 6) (integer) 5811 3) 1) "name" 2) "D" 3) "pending" 4) (integer) 0 5) "idle" 6) (integer) 663027
Comment From: ghost
I'm not sure if resetting the idle time for a consumer when it does an XPENDING is desired or not, but I hope if this is changed, there is some other method created to enable resetting a consumer idle time when there are no messages for it to read.
My particular use case is using the idle time to determine "active" streams/groups/consumers, whether or not there are messages for the consumer to read. So, just because there are no messages being added to a stream, I need a method to determine which consumers are actively trying to read from each stream.
To be honest, using XPENDING for this doesn't seem correct, but it's the only method I've been able to find. Thanks a lot.
Comment From: antirez
This is fixed in Redis unstable and 6.0 branch (so next 6.0.x will have it): bce3d08c66a1bf22ea852295a57b92a8024d4a1b
Should we fix it for 5.0 as well @guybe7?
Comment From: guybe7
@antirez sure, why not IIRC anyway we need to release 5.0.10 that has https://github.com/antirez/redis/commit/57a0c9c98d3bb966d6191fd1657df010cfe060fb
Comment From: casret
@qtrakker Not to hijack this issue, but I have the same use case, and was surprised a XREADGROUP BLOCK doesn't reset the idle time, did you find another way to track consumer activity?
Comment From: JVecsei
Having the same issue right now. I am running a scheduler which should only claim messages from permanently removed nodes.
I saw in the release notes that this was fixed in redis 6.0. Was this also changed in any of the 5.X versions?
Comment From: guybe7
@JVecsei no it was not... can you work with 6.0.x?
Comment From: JVecsei
@guybe7
Thanks for the quick reply! I am using Amazon ElastiCache which seems to only support Redis up to version 5.0.6. (docs)
Then I will have to think about another workaround.
Thanks again.
Comment From: oranagra
closing this since the issue is solved in 6.0 and unstable. marking it as candidate for 5.0 backport if we ever have another release there.
Comment From: oranagra
handled in 5.0.10