[Feature Request] LPUSH expired keys on a list.

[GoogleCodeExporter]

Feature:
Option to LPUSH expired keys on a list. This option should be OFF by default.

One way to implement this:
Have a redis.conf option to specify the key of a list to use.

Usefulness of this feature:
A BRPOP could be done on the list with the expired keys. This would allow you 
to perform actions when keys expire in a event driven way.

Generic use case:
You could associate "things" with database keys. When the keys expire these 
things could be cleaned up. "Things" could be files on the hdd, other database 
keys, etc.

Original issue reported on code.google.com by seth.bu...@gmail.com on 4 Mar 2011 at 11:10

[GoogleCodeExporter]

This is an interesting proposal, but there are many operational concerns. For 
instance: if keys are expired due to maxmemory, adding them to a list 
potentially only *grows* memory usage instead of shrinking it. Another thing: 
it should not be expired. There are more, but the main thing is that adding 
such a feature requires adding in exceptions to "normal" use all over the place.

Instead, I would suggest implementing something like this yourself using for 
instance a sorted set. If you combine every set with expire or independent 
expire call with a ZADD to a sorted set holding the key names and their 
expected time to be expired, you can have workers do a ZRANGEBYSCORE on this 
sorted set to get the keys that need to be cleaned up. Optionally, you can 
check the TTL for these keys and re-add them if they are not expired yet. This 
approach is non-native and does require a little bit more work (and memory), 
but does allow you to tailor it exactly to your specific needs.

Leaving the issue open for now, so we can have some discussion about this.

Original comment by pcnoordh...@gmail.com on 6 Mar 2011 at 3:43

[GoogleCodeExporter]

Pieter,

I've thought long and hard about what you've said.

I appreciate the need to have the features in redis compose well. It sounds 
like adding this feature would be a lot more complex than I'd thought. Perhaps 
more than the feature is worth?

I've come up with an alternate plan for my application which is event driven 
and doesn't require this feature. I'm going to associate each child pointer 
(which exists as a GUID in a ZSET) in the tree with a key that has expiration 
set on it. When I query a tree node to get all child node pointers I'll do a 
MGET on all keys associated with the child node pointers. If any of the keys 
are missing I'll lazily remove their associated child pointers asynchronously. 
I think this will work well.

I don't think my use case for the "LPUSH expire" feature is as compelling as I 
initially thought since I'm now convinced I don't need it. :-)

Please close/reject this feature request if you'd like. I really appreciate 
your careful consideration of this feature request.

Original comment by seth.bu...@gmail.com on 6 Mar 2011 at 9:00

[GoogleCodeExporter]

Sounds like a good plan. Good luck!

Original comment by pcnoordh...@gmail.com on 7 Mar 2011 at 8:49

• Changed state: WontFix