if you were using a key to track say, failed logins, by ip address and you wanted a persistent lock until there were no attempts for 5 minutes you would keep calling incr() so you have a failure count, resetting the expiration each time and then when it's not touched for 5 minutes it would fall off
that is a scenario that isn't possible right now On Fri, Sep 11, 2009 at 1:13 AM, Clint Webb <[email protected]> wrote: > Why are you putting an expiry on a key you are incrementing and > decrementing? I cant think of a situation where I would want to expire a > counter (other then letting it fall out the LRU). > > In fact, the only situation I can think of that could use an expiry would > follow the way it currently works. Ie, I'd set a key with a 5 minute > expiry, and then keep incrementing it for whatever reason, and then after 5 > minutes, the key goes away and I create another one. I do this for > tracking surges of hits from particular IP's (although I dont use 5 > minutes). > > I cant think of any reason where I would want to give the key a new expiry > that couldn't be taken care of by the LRU evictions. > > On Fri, Sep 11, 2009 at 1:20 AM, Adam Lee <[email protected]> wrote: >> >> On Thu, Sep 10, 2009 at 9:31 AM, Dean Michael Berris >> <[email protected]> wrote: >> > >> > Hi Guys, >> > >> > I recently checked the documentation about the memcached protocol and >> > while looking at supporting it in my C++ client, I'm looking at a >> > situation where I'm not sure whether it's possible to set the >> > expiration of a key through the incr/decr commands. From the >> > documentation, it seems that there's only a way to increment and >> > decrement, but not set the expiration of the key being >> > incremented/decremented. >> > >> > Is this by design? Should I file for a feature request for an >> > incr/decr that also updates the expiration of a cache key? >> > >> > This feature would be really useful for tracking keys -- maybe >> > tracking activity within a certain period of time. So something like >> > this algorithm would be easily supported: >> > >> > 1. The first time something happens, set a key to 0 in memcached, >> > expires in X seconds >> > 2. The next time something happens, increment the key (update the >> > expiration to X seconds) -- if the increment fails, that means the key >> > has expired, set the key to 0 again >> > 3. If the incremented value is higher than a certain number, then >> > you can do something about it (maybe there's abusive behaviour going >> > on, maybe a clicker bot or something) >> >> We use this exact functionality, with one key difference-- we set this >> expiration when we initialize the counter, but it doesn't get updated >> when we incr/decr. This is useful to implement any sort of counter-- >> rate limiting certain user actions, tracking occurrences of specific >> activities, etc... >> >> We ended up just building a generic McCounter class that you >> initialize with an expiration. It has get/set/incr/decr and takes >> care of all the behind-the-scenes work to make sure that the value >> exists in MC before trying to incr, etc. It's a super simple class >> and has proved infinitely useful-- perhaps you also want to build >> something along these lines. >> >> -- >> awl >
