key collisions

[Andy]

On Wed, 2007-02-14 at 08:10 -0500, Dave St.Germain wrote:
> hi, mark,
> I'm having the same problem with key collisions with the python  
> binding, and I was wondering if you've made any progress.  I haven't  
> been able to reproduce the problem in a test, but in production,  
> we'll encounter the problem all of a sudden after a while (the only  
> "solution" so far is to restart memcached).  The server returns the  
> wrong value for the requested key.  Not only that, but if you try a  
> get_many for key 'foo', you may get a response that has key 'bar' and  
> its value.
> Since I haven't been able to reproduce this behavior in a test, I  
> don't yet know if it's the python binding or memcached itself.
> Does anyone have any ideas?

Are you using persistent connections and does it go away if you turn off
persistent connections?

I didn't run into this problem with memcached and PHP, but I've run into
it with other things and I've always thought it _might_ be a problem
with memcached depending on how the client library is written.  If your
client code dies before it has drained the input buffer of the results
of memcached requests, that data could end up being available to
whichever process picks up that connection again.  And it may just so
happen that there is a full response to a get, so things get out of
sync.

Are there any protections in any client code to help avoid this, like
forcefully draining the input buffer on a persistent connection at
initialization time, when it knows no valid requests have been made yet?

Or some kind of "echo" command that the client can use to "reset" the
connection to a known state ("echo some-random-string", then read up
until you see some-random-string) might help.

-- 
Andy <memcached at thwartedefforts.org>