What are the semantics of flush_all with delay

[Paul Lindner]

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.


-- 
Paul Lindner        ||||| | | | |  |  |  |   |   |
lindner at inuus.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.danga.com/pipermail/memcached/attachments/20070403/1fb0f2da/attachment.pgp