I've pushed a test that reproduced this issue and a fix for it. Thanks for the report. :)
http://github.com/dustin/memcached/commit/bad6c614e58639d0685706f17dc9562323c30f39 On Feb 11, 4:47 pm, Dustin <[email protected]> wrote: > Hey, that's great. Bugs are here: > http://code.google.com/p/memcached/issues/list > > I'll take a look and add some tests for this. > > On Feb 11, 4:40 pm, jd <[email protected]> wrote: > > > Hey all, > > I have been unable to find a bug database for memcached, so if one > > exists, feel free to point me to it. For now, I'll just describe the > > issue I've seen. > > > Basically, it appears that the integrity of 'cas' is tainted. Both > > the 'incr' and 'decr' operations do not update the cas ID of the key. > > I realize that this is a fringe case, but I think for something like > > 'cas' to be effective and reliable, it needs to stay true to its > > principal. I should be guaranteed that when the cas command accepts > > my update, that I am replacing the value I think I am. See below for > > an example of the current behavior: > > > set test 0 0 1 > > 0 > > STORED > > gets test > > VALUE test 0 1 2 # CAS ID is 2 > > 0 > > END > > incr test 1 > > 1 > > gets test > > VALUE test 0 1 2 # CAS ID is still 2, despite the key's value > > changing > > 1 > > END > > cas test 0 0 1 2 > > 9 > > STORED # This would've succeeded no matter when I got > > that > > cas ID. It's useless. > > gets test > > VALUE test 0 1 3 > > 9 > > END > > > Regards, > > Jason DiCioccio
