another one weirdness

[Brad Fitzpatrick]

Avva,

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.

Consider:

t=1.0s
t=1.1s  set FOO = OLD
t=1.2s  flush_all
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
t=1.2s's flush_all.

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.
>
> --
> avva
>
>