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. ;-)
Liz
More information about the memcached
mailing list