Should SET operation returned STORED when unix time expiration has already past

[GoogleCodeExporter]

What steps will reproduce the problem?
1. set a key with a unix time expiration in the past
2. see that the response is STORED
3. get that key verifies it is no longer there

What is the expected output? What do you see instead?
I would expect the output of the SET operation is NOT_STORED, seeing STORED 
instead.

What version of the product are you using? On what operating system?
memcached 1.4.4-3.el6, from RHS 2.0 (Red Hat Storage, RHEL 6.2 derivative)

Please provide any additional information below.
The client is OpenStack Swift's swift.common.memcached, which uses unix time 
for all operations. The default timeout for one of the Swift keys is 60 
seconds, and when my client server fell behind the memcached server by more 
than 60 seconds, the SET operation returned STORED but it immediately timed out.

Would it be useful to have memcached return NOT_STORED when the time has 
already expired? Or perhaps some other ERROR?

Original issue reported on code.google.com by peter.a....@gmail.com on 7 Nov 2012 at 8:43

[GoogleCodeExporter]

Settting values in the past is useful for some usage scenarios.

Why is swift setting an explicit unix timestamp instead of using a relative 
value of "60" for the timeout? That's a severe design issue on their end to 
limit you to just unix timestamps.

Original comment by dorma...@rydia.net on 7 Nov 2012 at 8:48

[GoogleCodeExporter]

Agreed, on both counts.

It was not immediately obvious to me that it was a time skew problem, as it was 
working from one client and not from another client. Both SET operations 
returned STORED. But that is because I modified their client implementation to 
not use "noreply" so as to check what was happening.

I'll file a bug against OpenStack Swift as well, referencing this bug.

So do folks set values using an absolute (unix) time in the past to verify 
memcached is functioning? Or perhaps that a key/value pair is storable (not too 
big or something)?

Thanks for indulging me here.

Original comment by peter.a....@gmail.com on 7 Nov 2012 at 9:18

[GoogleCodeExporter]

ok, closing out this ticket.

Two examples: Clearing values with CAS without using the binary protocol 
(essentially delete-with-CAS)

Or testing add locks (there's an example on the wiki somewhere). Doing an add 
with an old unix timestamp is like doing a fetch test without being forced to 
fetch the value or overwrite it with junk.

there're more, I'm sure.

Original comment by dorma...@rydia.net on 7 Nov 2012 at 9:23

• Changed state: Invalid

[GoogleCodeExporter]

Entered bug in OpenStack Swift: https://bugs.launchpad.net/swift/+bug/1076148

Original comment by peter.a....@gmail.com on 7 Nov 2012 at 9:28

[GoogleCodeExporter]

So it appears OpenStack Swift uses absolute times because they allow users to 
set timeout values greater than 30 days, which is the limit used by memcached 
to determine if a timeout value is a delta or an absolute time. See the 
aforementioned bug if interested.

Original comment by peter.a....@gmail.com on 9 Nov 2012 at 9:37

[GoogleCodeExporter]

I imagine they could, you know, add like an if or something which would use a 
unix timestamp or a delta depending how long the requested cache time was.

But I'm not like, a software engineer or anything, clearly.

Original comment by dorma...@rydia.net on 9 Nov 2012 at 9:41

[GoogleCodeExporter]

;) Clearly.

Original comment by peter.a....@gmail.com on 9 Nov 2012 at 10:21