memcache python API key collisionsFwd: key collisions

rkmr.em at gmail.com rkmr.em at gmail.com
Wed Mar 21 23:10:32 UTC 2007


Thanks a lot, I will forward this again to the maintainer and try to
get it patched.
I hope this ends my long standing problem of memcached key collisions!
cheers


On 3/21/07, Dave St.Germain <dcs at tabblo.com> wrote:
> I submitted a patch back to the maintainer to fix exactly this
> problem.  It's simple:  make Client subclass threading.local
> (requires python 2.4 or greater)
>
> 65c65,73
> < class Client:
> ---
>  > try:
>  >     # Only exists in Python 2.4+
>  >     from threading import local
>  > except ImportError:
>  >     # TODO:  add the pure-python local implementation
>  >     class local(object):
>  >         pass
>  >
>  > class Client(local):
> 107a116
>  >         local.__init__(self)
>
>
>
>
> On Mar 21, 2007, at 6:54 PM, rkmr.em at gmail.com wrote:
>
> > Yeah, I am using same memcache object across multiple threads I think.
> > Can you give the example of how you use it in a multi-threaded app?
> >
> >
> >
> > On 3/21/07, Philip Neustrom <philipn at gmail.com> wrote:
> >> I've never been able to reproduce this, and I haven't seen any test
> >> code that reproduces it, either.  I'd be glad to fix this myself if I
> >> knew what was going wrong here :/
> >>
> >> From what I understand, though, you're using the same memcache object
> >> across multiple threads without considering what happens when
> >> multiple
> >> clients step on each other's feet?
> >>
> >> --Philip Neustrom
> >>
> >> On 3/21/07, rkmr.em at gmail.com <rkmr.em at gmail.com> wrote:
> >> > Hi
> >> > Does any have a patch for this python memcached client api?
> >> >
> >> > "
> >> > for (namely, as I understand it, cleaning up an existing
> >> connection when
> >> > the application using it is terminated early), I would certainly
> >> review and
> >> > "
> >> >
> >> > To solve this problem of key collisions.
> >> > http://lists.danga.com/pipermail/memcached/2007-February/
> >> 003605.html
> >> > This is what the author or python memcache client api had to say.
> >> > It will be great to have this patch.
> >> > thanks a lot!
> >> >
> >> > ---------- Forwarded message ----------
> >> > From: Sean Reifschneider <>
> >> > Date: Mar 21, 2007 3:07 PM
> >> > Subject: Re: memcache python API key collisionsFwd: key collisions
> >> > To: "rkmr.em at gmail.com" <rkmr.em at gmail.com>
> >> >
> >> >
> >> > On Wed, Mar 21, 2007 at 02:27:28PM -0700, rkmr.em at gmail.com wrote:
> >> > >I hope your conference went great. Will you now have time to
> >> work on
> >> > >the key collisions problem in python api for memcache?
> >> >
> >> > If someone can provide a patch to provide the functionality you
> >> are looking
> >> > for (namely, as I understand it, cleaning up an existing
> >> connection when
> >> > the application using it is terminated early), I would certainly
> >> review and
> >> > include it.  However, it's not something I'm going to be able to
> >> resolve
> >> > myself.  From what I can tell of the description, the problem is
> >> largely in
> >> > your use of the client code (re-using an out-of-sync handle).  I
> >> just don't
> >> > have time to develop and test a fix to this within the client code.
> >> >
> >> > Thanks,
> >> > Sean
> >> > --
> >> >  This message is REALLY offensive, so I ROT-13d it TWICE.
> >> >                 -- Sean Reifschneider being silly on #python, 2000
> >> >
> >>
>
>


More information about the memcached mailing list