What are the semantics of flush_all with delay

Elizabeth Mattijsen liz at dijkmat.nl
Tue Apr 3 18:08:29 UTC 2007

At 8:40 AM -0700 4/3/07, Paul Lindner wrote:
>On Mon, Apr 02, 2007 at 10:31:49PM +0200, Elizabeth Mattijsen wrote:
>>  At 1:24 PM -0700 4/2/07, Dustin Sallings wrote:
>>  >	I was writing a test suite for my java client that talked to
>>  >an actual memcached and found that I couldn't figure out exactly
>>  >what flush_all with a delay is supposed to do.
>>  >
>>  >	My test for delete works something like this:
>>  >
>>  >	validate object isn't there
>>  >	set object
>>  >	validate object is there with my value
>>  >	delete(5)
>>  >	validate object isn't there
>>  >	validate add does not set object
>>  >	validate update does not set object
>>  >	validate set works fine
>>  >
>>  >	I tried the same thing for flush_all, and the assertions
>>  >following the delayed flush don't seem to make much sense.
>>  >
>>  >	I was running my tests against memcached 1.2.1 in case it
>>  >makes a difference.
>>  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.).
>Do you mind if I incorporate the previous two paragraphs into the
>protocol.txt document?  It finally made it clear to me the intent of
>the delay arg to flush_all.

Be my guest!  I guess I should have done that as part of the original 
patch that I submitted.  ;-)


More information about the memcached mailing list