Bug 745833 (EDG-74)

Summary: incorrect flush_all expiration time interpretation
Product: [JBoss] JBoss Data Grid 5 Reporter: Michal Linhard <mlinhard>
Component: InfinispanAssignee: Default User <jbpapp-maint>
Status: CLOSED NEXTRELEASE QA Contact:
Severity: high Docs Contact:
Priority: high    
Version: unspecifiedCC: nobody
Target Milestone: ---   
Target Release: EAP 5.1.0 EDG TP   
Hardware: Unspecified   
OS: Unspecified   
URL: http://jira.jboss.org/jira/browse/EDG-74
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2010-12-01 14:44:34 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

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