another one weirdness
Thu, 8 Apr 2004 11:15:17 -0700 (PDT)
It's because the flush_all just sets the "flush time", and then a new item
is stored in the same second, then a subsequent "get" finds the item and
sees it was created <= flush_time, therefore ignores it.
Which is arguably safer behavior.
t=1.1s set FOO = OLD
t=1.3s set FOO = NEW
t=1.4s get FOO
Currently FOO will be empty, since at second granularity foo-NEW is at
time 1, and so is flush_all, so 1 <= 1 -> ignore it.
But if we changed that to flush_all < item_time, and the t=1.3s event
never occured, it'd be possible at t=1.4s to get FOO=OLD even after
My knee-jerk answer: it's a cache for christ's sake... you're supposed to
deal with empty answers. The current behavior is fine.
But the better answer: higher granularity.
On Thu, 8 Apr 2004, Anatoly Vorobey wrote:
> On Thu, Apr 08, 2004 at 09:18:40PM +0400, Antony Dovgal wrote:
> > Hi again.
> > I've got another one question about flush_all.
> > Just found an interesting effect:
> > After FLUSH_ALL some subsequent SET's report OK (i.e. "STORED"), but GET's fail.
> > But if do FLUSH_ALL and than sleep() for a second, subsequent SET's and GET's work ok.
> flush_all should be instantaneous. However, it doesn't actually delete
> the items, it just marks them all as obsolete and able to be replaced.
> This behaviour seems wrong and I'll try to reproduce and investigate.