Bug in PHP client?
Brad Fitzpatrick
brad@danga.com
Mon, 22 Sep 2003 17:15:02 -0700 (PDT)
Thanks. I'm feeling a bit stressed lately now that memcached is growing
in popularity and the PHP client is getting bug reports I can't fix, and
it reflects poorly on memcached as a whole.
A stream-based library would seem much less error-prone.
On Mon, 22 Sep 2003, Justin Matlock wrote:
> I was pretty sure we had removed that entire block already and Ryan had
> committed the change.
>
> Hurm.. There are a few other major problems in that _load_items method --
> but I haven't had time to debug the streams support properly to rewrite it.
> I've been working on an actual C-based PHP extension for memcached -- it's
> about 20% faster than the script (although it's about the same speed if you
> use Zend Accelerator with your scripts).
>
> I'll post both here by this weekend.
>
> J
>
> ----- Original Message -----
> From: "Russ Garrett" <rg@tcslon.com>
> To: <memcached@lists.danga.com>
> Sent: Sunday, September 21, 2003 12:09 PM
> Subject: Bug in PHP client?
>
>
> > We noticed that pages on our site would hang for no particular reason -
> > and after extensive debugging (such a pain on PHP), I traced it down to
> > the memcached client - specifically this part (in _load_items, about
> > line 1056):
> >
> > // skip over the extra return or newline
> > if($line == "\r" || $line == "\n")
> > continue;
> >
> > The problem is this: if the object to be retrieved is of a specific
> > length, then the last chunk of data retrieved will consist just of the
> > closing \n from memcached. In this case the if statement will be true,
> > and it'll continue back to the top of the while loop on line 1006. But
> > since this was the closing \n, it's the last chunk of data recieved, and
> > so it'll block for ever on socket_read.
> >
> > I just commented those two lines out - I can't see why you'd want to
> > skip over that anyway. But I suggest putting a timeout on that read call
> > (I assume that's possible - I haven't looked at the PHP raw sockets
> > interface).
> >
> > Cheers,
> >
> > Russ
> >
> > --
> > Russ Garrett Last.fm
> > russ@last.fm http://www.last.fm
> >
> >
>
>