setnx and expire?

[Clifford T. Matthews]

I'd like to rate-limit using Redis.

I thought I could just do something like:

return unless R.setnx key, "token"
R.expire key, ttl

but it appears that in 2.0.x setnx calls setGenericCommand which contains
the code:

if (nx) deleteIfVolatile(c->db,key);

which has the side effect of making every setnx for a given key
succeed if there is an expiration time associated with the key. We're
using 2.0.4 in production, so I've actually tested and seen the
unfortunate behavior that I describe.

I thought there would be a chance that 2.2.x would be better, but
reading the source to 2.2.2 suggests that when setnx is being executed
there's no explicit check to see if the key has expired, so--if I
understand the expiration algorightm--that leaves it up to chance as
to whether the key will expire on time. When I run tests on a lightly
loaded 2.2.2 Redis instance, things work fine, but I'm not
particularly convinced that the right thing will happen when we have a
ton of keys that should expire in the future.

Am I misreading and/or misunderstanding?

If not, would a patch that has 2.2.x explicitly test the expiration
date for setnx be welcome?
--
Cliff Matthews
work: c...@devctm.com fun: c...@sceim.net

[Josiah Carlson]

See http://dr-josiah.blogspot.com/2011/02/some-redis-use-cases.html
for a 2 function implementation of rate limiting that uses 1 zset for
counts, and 1 zset for reset timers (to address the auto expire
issues). The Python can easily be translated to other languages.

Regards,
- Josiah

> --
> You received this message because you are subscribed to the Google Groups "Redis DB" group.
> To post to this group, send email to redi...@googlegroups.com.
> To unsubscribe from this group, send email to redis-db+u...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/redis-db?hl=en.
>
>