<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META NAME="Generator" CONTENT="MS Exchange Server version 6.5.7226.0">
<TITLE>Re: Libmemcache/php-mcache issues</TITLE>
</HEAD>
<BODY>
<DIV id=idOWAReplyText55365 dir=ltr>
<DIV dir=ltr><FONT face=Arial color=#000000 size=2>Hey,</FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2></FONT> </DIV>
<DIV dir=ltr><FONT face=Arial size=2>Being the author of php-mcache I can shed
some light. First, as Garrett said libmemcache does like to log errors to
stderr and exit when it considers them fatal, but the most recent beta's support
overriding this behavior and along with the most recent php-mcache beta's fix
this and log the errors correctly via php's error handling and never exit (as
that would exit the apache thread/process... which is obviously not
desirable). </FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2></FONT> </DIV>
<DIV dir=ltr><FONT face=Arial size=2>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.</FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2></FONT> </DIV>
<DIV dir=ltr><FONT face=Arial size=2>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.</FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2></FONT> </DIV>
<DIV dir=ltr><FONT face=Arial size=2>John</FONT></DIV></DIV>
<DIV dir=ltr><BR>
<HR tabIndex=-1>
<FONT face=Tahoma size=2><B>From:</B> memcached-bounces@lists.danga.com on
behalf of Garrett Rooney<BR><B>Sent:</B> Sun 9/4/2005 10:12 AM<BR><B>To:</B>
Russ Garrett<BR><B>Cc:</B> memcached@lists.danga.com<BR><B>Subject:</B> Re:
Libmemcache/php-mcache issues<BR></FONT><BR></DIV>
<DIV>
<P><FONT size=2>Russ Garrett wrote:<BR>> OK, today I tried moving our live
site over to the mcache PHP extension.<BR>> Previously we were using the PECL
extension with a custom multi-server<BR>> wrapper, however this caused
problems with failover (i.e., it doesn't),<BR>> and we'd much rather be
running on libmemcache which seems like a much<BR>> more reliable
solution.<BR>><BR>> So the setup is:<BR>><BR>> mcache version
1.2.0-beta8<BR>> libmemcache version 1.4.0.b5<BR>> memcached version
1.1.11<BR>><BR>> We are (or rather, were, since we've rolled back) getting
loads of<BR>> errors like this (probably 5 per second):<BR>><BR>>
Sep 4 15:54:20 local@www5 httpd[3256]: [error] PHP Fatal
error: <BR>> memcache(4) protocol error - \r\nWEEKLY UK AUDIOSCROBBLER
ARTIST<BR>> CHART\r\nW...<BR>> Sep 4 15:54:16 local@www3
httpd[27668]: [error] PHP Fatal error: <BR>> memcache(4) protocol error
- VALUE c012ba4abdd9f4f8b4ab1f1386957dd5 1<BR>>
4043\r\nO:5:"group":..<BR>> Sep 4 15:54:17 local@www2 httpd[3275]:
[error] PHP Fatal error: <BR>> read(2) failed - server unexpectedly
closed connection in<BR>> /nfsroot/web/site/www.last.fm/core/memcached.php on
line 43<BR>> Sep 4 15:53:45 local@www3 httpd[27673]: [error] PHP Fatal
error: <BR>> memcache(4) protocol error - no \\r before \\n in<BR>>
/nfsroot/web/site/www.last.fm/core/memca<BR>> ched.php on line
43<BR>><BR>> Firstly, why are these fatal errors? Surely libmemcache
should simply<BR>> log a notice, and then close/reopen the connection to
reset it, hence<BR>> not completely breaking the site if something goes wrong
with memcached.<BR>><BR>> Is this some sort of version incompatibility, or
an issue in libmemcache<BR>> itself? It only seems to happen on a certain
(small) subset of values. I<BR>> hope to isolate these keys and see if I can
reproduce these errors on<BR>> our development site.<BR><BR>I'm not sure if
you're running into the same sort of problems we did,<BR>but we recently tried
to use libmemcache and eventually threw up our<BR>hands and switched to
apr_memcache instead, despite the extra<BR>dependencies it introduced into the
system.<BR><BR>libmemcache seems to have this lovely habit of logging an awful
lot of<BR>data to stderr in some situations (specifically it got into loops
when<BR>it couldn't talk to a server for some reason where all it would do
is<BR>keep dumping messages to stderr) and even more fun, deciding that
an<BR>entire class of errors are fatal and exiting in response. The
beautiful<BR>thing is that this class of errors often seems to be a result of
bugs in<BR>the actual libmemcache library (the big one we found was checking
errno<BR>after a strtol call without zeroing errno out first and thus picking
up<BR>an old errno value, thus incorrectly assuming an error had occurred
when<BR>in fact nothing had gone wrong).<BR><BR>We fixed the strtol bugs
locally, but the looping on failure to connect<BR>to the server was just too
much (it didn't help that the code in<BR>question was rather #ifdef happy and
hard to follow), so we gave up and<BR>ported our code. No problems with
apr_memcache so far.<BR><BR>-garrett<BR></FONT></P></DIV>
</BODY>
</HTML>