We're using memcache to store short-lived, incremented keys for the
purposes of rate-limiting. Right now, we're trying to debug an issue where
these keys stick around much longer than we expect.
While investigating the issue, I found an example key that we believe we've
set with an expiry time of 300 seconds (five minutes). Over the course of
several hours, I was able to GET it, with the value maintained.
The only way I could figure out to find a key's expiry time (as actually
recorded inside memcache) is through the 'stats cachedump' command, like so:
[$]> (sleep 1; echo "stats cachedump 1 0"; sleep 1; echo "quit";) |
telnet localhost 11211 | grep 'my_key'
ITEM my_key [2 b; 1389767076 s]
As I understand it[0], that last integer value is the unix timestamp
representing the item's expiry time. That time, however, is roughly one
week ago[1]. I double-checked, and the system date is set correctly.
Now, I know that memcached doesn't delete items when they expire, but the
protocol explicitly states that I should not be able to get a key if its
expiry time has passed[2]. Yet, that appears to be happening.
Given this is a core feature of memcached, my assumption is that this is
not, in fact, a bug in memcached, but rather a misunderstanding on my part.
As such, I'd be grateful if you can point out any incorrect assumptions
I've made, or provide any advice on where I should be looking.
We're using memcached 1.4.15.
Thanks.
- P
[0]: http://stackoverflow.com/q/1645764/120999
[1]: https://www.wolframalpha.com/input/?i=1389767076+unixtime
[2]:
https://github.com/memcached/memcached/blob/master/doc/protocol.txt#L165-L168
--
---
You received this message because you are subscribed to the Google Groups
"memcached" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/groups/opt_out.
