liuqian1990 / memcached

Automatically exported from code.google.com/p/memcached
0 stars 0 forks source link

Large expiration values result in no value being stored #330

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
What steps will reproduce the problem?
1. telnet localhost 11211
2. Type into the telnet session (> lines are the server responses): 
set somekey 0 1000000000 11
hello world
> STORED
get somekey
> END

set otherkey 0 60 11
hello world
>STORED
get otherkey
>VALUE otherkey 0 11
>hello world
>END

What is the expected output? What do you see instead?
I would expect to be able to store values with expiration value is over 30 days 
(2592000 seconds). Or, if that is not possible, at the very least, I would 
expect an error on attempting to store. Instead, the server silently accepts 
the set command, and returns nothing on the subsequent get. The silent failure 
is a bit of a slap in the face, not described in the protocol specification at 
https://github.com/memcached/memcached/blob/master/doc/protocol.txt

What version of the product are you using? On what operating system?
memcached 1.4.14 on Mac OSX 10.6.8, installed using homebrew

Please provide any additional information below.

Original issue reported on code.google.com by CTwene...@gmail.com on 28 Jun 2013 at 10:03

GoogleCodeExporter commented 9 years ago
Expiration times
----------------

Some commands involve a client sending some kind of expiration time
(relative to an item or to an operation requested by the client) to
the server. In all such cases, the actual value sent may either be
Unix time (number of seconds since January 1, 1970, as a 32-bit
value), or a number of seconds starting from current time. In the
latter case, this number of seconds may not exceed 60*60*24*30 (number
of seconds in 30 days); if the number sent by a client is larger than
that, the server will consider it to be real Unix time value rather
than an offset from current time.

For emphasis:

if the number sent by a client is larger than
that, the server will consider it to be real Unix time value rather
than an offset from current time.

To repeat:

If it's over 30 days, it treats it like a datetime in unix timestamp format. So 
you can set larger values, but you have to treat them differently.

Original comment by dorma...@rydia.net on 28 Jun 2013 at 11:09