Bug 745833 (EDG-74) - incorrect flush_all expiration time interpretation
Summary: incorrect flush_all expiration time interpretation
Keywords:
Status: CLOSED NEXTRELEASE
Alias: EDG-74
Product: JBoss Data Grid 5
Classification: JBoss
Component: Infinispan
Version: unspecified
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: ---
: EAP 5.1.0 EDG TP
Assignee: Default User
QA Contact:
URL: http://jira.jboss.org/jira/browse/EDG-74
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-11-22 16:25 UTC by Michal Linhard
Modified: 2014-03-17 04:01 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2010-12-01 14:44:34 UTC
Type: Bug


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker EDG-74 0 None None None Never

Description Michal Linhard 2010-11-22 16:25:57 UTC
project_key: EDG

memcached server module flush_all command should interpret the expiration time value same way as in storage commands.

expiration time is signed 32bit integer ranging -2147483648 .. 2147483647
that means different things according to different ranges it belongs to:
-2147483648 .. -1 = not sure how this is supposed to be treated (I'm waiting for an answer on http://code.google.com/p/memcached/issues/detail?id=169)
0 = no expiration time
1 .. 2592000 (60*60*24*30) = the value is treated as seconds from now
2592001 .. 2147483647 = the value is treated as absolute unix time

now we treat every value as number of seconds

Comment 1 Galder Zamarreño 2010-11-25 10:26:34 UTC
Hmm, reading https://github.com/memcached/memcached/blob/master/doc/protocol.txt 
it's unclear whether it should be treated exactly in the same way
as the storage commands. It simply refers to it as a delay in
seconds:

"The intent of flush_all with a delay, was that in a setting where you
have a pool of memcached servers, and you need to flush all content,
you have the option of not resetting all memcached servers at the
same time (which could e.g. cause a spike in database load with all
clients suddenly needing to recreate content that would otherwise
have been found in the memcached daemon).

The delay option allows you to have them reset in e.g. 10 second
intervals (by passing 0 to the first, 10 to the second, 20 to the
third, etc. etc.)."

Did you do any testing against original Memcached that made you
think that it should be treated in the same way as storage commands?

As a FYI, in storage commands, I'm treating negative expiration times
as 0, no expiration.

Comment 2 Michal Linhard 2010-11-25 10:53:01 UTC
yes original memcached treats it this way.

What made me think all expiration times in all commands should be treated this way is the way which "Expiration times" section of the protocol is formulated: "
Some commands involve a client sending some kind of expiration time ..." referring possibly to any command that contains "some kind of expiration time".

Comment 3 Galder Zamarreño 2010-11-30 11:08:54 UTC
Link: Added: This issue depends ISPN-810



Note You need to log in before you can comment on or make changes to this bug.