sidekiq-ent limiter timeouts from redis-client revisited about sidekiq HOT 7 CLOSED

Oh, by the way, in case you were wondering: we're not using a wait_timeout of less than a millisecond. It's that on a subsequent iteration of the while loop, diff is sometimes that small.

from sidekiq.

Ok, I see:

1. A limiter call loops until the diff value gets down to <0.001.
2. Sidekiq issues a BLMOVE call with timeout <0.001.
3. Because Redis treats that as a zero timeout, BLMOVE times out on the client-side after 1 second.

Thank you for figuring that out!

from sidekiq.

Redis 7.2.3 does not display this behavior. It pauses:

$ redis-cli
127.0.0.1:6379> BLMOVE foo bar LEFT RIGHT 0.1
(nil)
127.0.0.1:6379> BLMOVE foo bar LEFT RIGHT 0.01
(nil)
127.0.0.1:6379> BLMOVE foo bar LEFT RIGHT 0.001
(nil)
127.0.0.1:6379> BLMOVE foo bar LEFT RIGHT 0.0001
(nil)
127.0.0.1:6379> BLMOVE foo bar LEFT RIGHT 0.000001
(nil)
127.0.0.1:6379> BLMOVE foo bar LEFT RIGHT 0

Whereas 0 actually blocks.

from sidekiq.

Interesting. I just verified the behavior I described above (on Redis 7.0) using redis-cli directly (just in case there was an issue in redis-client). It's blocking with a timeout of 0.001.

So this is either Redis version-dependent or possibly platform-dependent (this redis server is running on linux).

from sidekiq.

Oh, also: the exact version I'm looking at is 7.0.7. A colleague just tried this out on his locally-installed redis (7.0.11 on macos). A timeout of 0.001 did not block.

from sidekiq.

Okay, found it: redis/redis@574a49b

In fact, this seems to have been fixed in the very next version (7.0.8). So that's some bad luck for us.

from sidekiq.

Thanks for all the research. It appears to be a Redis bug which has been fixed so I'll close with no action.

from sidekiq.