brad at danga.com
Sun Dec 24 19:05:03 UTC 2006
Thanks. I'm looking into this now. I have some theories.... probably
this rel_time_t underflow:
return (rel_time_t) (exptime - stats.started);
On Fri, 22 Dec 2006, Adam Dixon wrote:
> Hello all,
> Ive attempted and tested to what I am able, my modified expirations.t
> file. Forgive me if I have it wrong.
> Its a similar test to something that is stored with a exptime of
> time() - 1, however the test is time - 10. 10 is arbitrary, could be
> any number above memcached.uptime value. I think you can go as low as
> 5 or so with all the sleeping going on in the test file.
> I figure this as valid as if I change the subtraction value from 10 to
> 1 it passes.
> My output is as follows;
> [adixon at dixon t]$ perl expirations.t
> ok 1 - stored foo
> ok 2 - foo == 'fooval'
> ok 3 - foo == <undef>
> ok 4 - stored foo
> ok 5 - already expired
> ok 6 - stored foo
> ok 7 - foo == 'foov+1'
> ok 8 - now expired
> ok 9 - stored boo
> not ok 10 - now expired
> # Failed test
> (/home/adixon/memcached-1.2.1/t//lib/MemcachedTest.pm at line 46)
> # got: 'VALUE boo 0 6
> # booval
> # END
> # '
> # expected: 'END
> # '
> # Looks like you failed 1 tests of 10.
> Is that the kind of test which will help determine if its a bug?
> Kind regards,
> On 12/22/06, Ask Bjørn Hansen <ask at develooper.com> wrote:
> > On Dec 21, 2006, at 20:57, Adam Dixon wrote:
> > > So can anyone confirm this behavior? It maintains this behavior in
> > > 1.2.1 also.
> > If you can write your test as a standard .t file then I'm sure it'll
> > be much easier to spot the bug (in your test or in memcached) and get
> > it fixed.
> > --
> > http://develooper.com/ - http://askask.com/
More information about the memcached