key collisions

[mark]

Hi Steven,

Is there some check that can be added to the memcache client which
takes care of this?
How to detect if there is some stale data sitting around?
It is not a good idea to start a new connection for every request right?
How to close an existing connection with memcache.py?


Thanks a lot!
mark

On 2/14/07, Steven Grimm <sgrimm at facebook.com> wrote:
> A previous email on this topic had what seems like the most likely
> explanation to me: you are using connections that persist across script
> runs (nothing wrong with that inherently) and aborting before reading an
> entire response. The next script comes along, sends its request, and
> reads the remainder of the response from the previous script.
>
> If you're aborting your scripts during the middle of reading a response
> -- and note that it wouldn't necessarily *your* code doing this; it
> could be aborted by the Python interpreter if you run out of memory, for
> example -- then you need to close the memcached connections to guarantee
> you don't have any stale data sitting around.
>
> -Steve
>
>
> mark wrote:
> > Hi Dave,
> > I have not made much progress! I had the same problem of not being
> > able to reproduce in the test environment! But in production I
> > consistently get the problem!
> > So I moved to cmemcached http://gijsbert.org/cmemcache/index.html
> > which is a python wrapper for the libmemcache. It seemed to solve the
> > problem at the beginning, but what was happening was if there was a
> > collision the app died with this message:
> >
> > [FATAL at 1170222010.740685] mcm_fetch_cmd():1176: memcache(4) protocol
> > error: server sent data for key not in request
> >
> >
> > I have not fixed this problem yet! It seems to be the same problem as
> > before but the client here checking for consistency I think.
> >
> > It will be great if someone can find a fix for this!
> > thanks
> > mark
> >
> > On 2/14/07, Dave St.Germain <dcs at tabblo.com> 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?
> >>
> >> Dave
> >>
> >>
> >>
> >> > Hi
> >> > I am consistently getting key collisions. There are total of around
> >> > 2000 key
> >> > value pairs cached.
> >> > This is how I prepare the key for memcached: md5.new(key).hexdigest
> >> > () where
> >> > key is the unique
> >> > id for the database row that I want to cache.
> >> > When I do a 'get' for a specific key, I get a value of a different
> >> > key.
> >> > I am using python-memcached as the client.
> >> > This is causing lot of problems. If anyone has faced similar issues
> >> > or has
> >> > any suggestions do reply.
> >> > cheers
> >> > mark
> >>
> >>
>
>