russ at last.fm
Mon Sep 5 02:16:46 PDT 2005
John McCaskey wrote:
> As to the protocol errors did you have existing cache data from before
> switching to php-mcache? The stored cache format for data from the
> PECL extension may be incompatible and you should definately restart
> memcached itself to clear the cace after switching the code. Apart
> from that it may be a libmemcached bug. I've also received a variety
> of reports of a segfault bug which I haven't had time to sufficiently
> investigate yet but have not been able to reproduce. Please keep in
> mind that the 1.2.0 series is beta and should be treated as such at
> the moment. Unfortunately there are known issues with the older
> versions of memcached that the 1.1.x series compiles against so its
> not a real clean situation there either.
I ran a flush_all on all our memcached boxes before putting it live, so
everything should have been clean. Even if (hypothetically) the stored
cache format was different, should that have mattered? Everything is
defined by byte offsets so the actual data itself should be irrelevant -
you grab x bytes and expect to find a \r\n at the end of them.
> Finally, as to the errors being fatal there are several levels
> internally in libmemcached which get mapped to either error, warning,
> or notice in php-mcache and I'll have to look into what the deal is
> with that specific error and why its fatal. An easy fix for you to
> quickly avoid any being fatal is to use the @ operator in front of the
> method call to supress the errors.
Aha, I didn't know you could do that for fatal errors... But that also
has the added problem of suppressing the errors in our logs too, which
is probably a bad thing.
russ at last.fm
More information about the memcached