possible bug in PHP API 1.0.8

Tue, 12 Aug 2003 16:53:07 -0700 (PDT)

Your patches are consistently backwards.  Not sure how you're making them,
but try doing it in reverse.  In any case, applied.

In the future, update ChangeLog.  And update MC_VERSION if you want me to
make a new release, which I assume you do with this bug.

Not sure why you changed getprotobyname("TCP") to SOL_TCP, but I included
it also.

New release will be on the site shortly.

On Tue, 12 Aug 2003, Ryan Gilfether wrote:

> Attached is a patch that fixes the problem found by Justin. His solution
> fixed the problem.
>
> Thanks,
> Ryan
>
> Brad Fitzpatrick wrote:
> > Justin,
> >
> > Thanks!  The PHP client is known to be buggy (discovered last week), and
> > Ryan said he's working on it.  Perhaps this is the only fix needed....
> >
> > Ryan?
> >
> > - Brad
> >
> >
> > On Tue, 12 Aug 2003, Justin Matlock wrote:
> >
> >
> >>Sorry for the extra-long email -- I just wanted to explain my thinking here,
> >>and go into excessive detail so someone can prove me wrong. :)
> >>
> >>I'm using the latest CVS snapshot of memcached, and the 1.0.8 PHP API, and
> >>the latest PHP 4.3.3 CVS tree, under Linux 2.4.21, Apache 2.0.47.  It was
> >>all working great on my devel box, but when I moved it over to production, I
> >>started getting a ton of "_load_items(): Bytes read is greater than
> >>requested data size." errors.  But the thing is:  the development box and
> >>production box are using the exact same memcached server.  They run the same
> >>OS, the same PHP version, the same *everything*.  They're even the same
> >>hardware (one serial number apart).  The *only* difference is the production
> >>box is on the same subnet as the memcached server -- the development one is
> >>on a different one.  Of course, I start doing a lot more testing on the
> >>development box, and I notice I was getting them over there too, just not as
> >>many.
> >>
> >>So I modified the script to give me more information (patch follows):
> >>
> >>=================
> >>1063,1064c1063,1064
> >><                                       $this->_debug("_load_items(): Bytes
> >>read is greater than requested data size.");
> >><
> >>---
> >>
> >>>                                      $this->_debug("_load_items(): Bytes
> >>
> >>read ($bytes_read) is greater than requested data size ($len).");
> >>
> >>>                                      $this->_debug("_load_items(): I
> >>
> >>received \"".urlencode($buf)."\"");
> >>=================
> >>
> >>Here's what I'm getting in my logs (I modified the debug handler to use my
> >>custom logging routines) -- add 7 for the "\r\nEND\r\n".  So we're getting
> >>back 2 characters instead of 1:
> >>
> >>(Data is "0")
> >>[03Aug12 154857] (INFO) #/profile/# <10.1.0.11> (u:1) _load_items(): Bytes
> >>read (9) is greater than requested data size (1).
> >>[03Aug12 154857] (INFO) #/profile/# <10.1.0.11> (u:1) _load_items(): I
> >>received "%0A2%0D%0AEND%0D%0A"
> >>
> >>(Data is "-1")
> >>[03Aug12 154926] (INFO) #/profile/# <10.1.0.11> (u:1) _load_items(): Bytes
> >>read (10) is greater than requested data size (2).
> >>[03Aug12 154926] (INFO) #/profile/# <10.1.0.11> (u:1) _load_items(): I
> >>received "%0A-1%0D%0AEND%0D%0A"
> >>
> >>(Data is a whole lot more than "0"  :) ):
> >>[03Aug12 154926] (INFO) #/profile/# <10.1.0.11> (u:1) _load_items(): Bytes
> >>read (165) is greater than requested data size (157).
> >>[03Aug12 154926] (INFO) #/profile/# <10.1.0.11> (u:1) _load_items(): I
> >>received "%0Aa%3A1%3A%7Bi%3A0%3Ba%3A5%3A%7Bs%3A7%3A%(for clarity, I cut off
> >>the end)
> >>
> >>The thing that sucks is I can't replicate this reliably.  I can hit reload
> >>over and over, and it will only happen 1 out of every 10 or so times, on
> >>random data coming back.  It's not just numerics, not text...
> >>
> >>I sniffed the connection, and here's one that barfed coming back from the
> >>server:
> >>
> >>VALUE profile_1_7028277b0e9405414ea71de0bdde789f_rank 0 2\r\n-1\r\nEND\r\n
> >>
> >>Looks okay to me; it follows the protocol, and there are two characters in
> >>the response.  Memcached isn't the culprit.  So on to the API...
> >>
> >>The problem appears to be with this line:
> >>$line = substr($line, strpos($line, "\r\n")+1, strlen($line));
> >>
> >>I added some more logging lines before and after it to see what the 'pre'
> >>and 'post' parsing results were.
> >>
> >>By only doing +1, you're just stripping off the \r.  It's always letting a
> >>\n through, even though it should be stripping it off.  The strange thing to
> >>me is sometimes it only lets a \n through, but sometimes it lets
> >>"\n0\r\nEND\r\n" through (this is when it breaks).  I'm still trying to
> >>track down why this is happening...
> >>
> >>In summary; I changed that +1 to a +2, and it always strips off the
> >>remaining \n.  From there, it works great.  I just pushed about 300 pages,
> >>and all came back without errors...
> >>
> >>Final patch:
> >>==============
> >>999c999
> >><                                       $line = substr($line, strpos($line,
> >>"\r\n")+1, strlen($line));
> >>---
> >>
> >>>                                      $line = substr($line, strpos($line,
> >>
> >>"\r\n")+2, strlen($line));
> >>===============
> >>
> >>"It works for me".  :)
> >>
> >>Justin
> >>
> >>----- Original Message -----
> >>From: "Ryan Gilfether" <ryan@gilfether.com>
> >>To: <memcached@lists.danga.com>
> >>Sent: Monday, August 11, 2003 12:37 AM
> >>Subject: Re: PHP API 1.0.7
> >>
> >>
> >>
> >>>yes, you're right, I didnt notice that a newline got included at the end
> >>>of the file. I'll be sure to remove it in future releases. Thanks for
> >>>pointing it out.
> >>>
> >>>Ryan
> >>>
> >>>Lisa Marie Seelye wrote:
> >>>
> >>>>On Sat, 2003-08-09 at 13:08, Ryan Gilfether wrote:
> >>>>
> >>>>
> >>>>>A new version of the PHP API has been completed, verson 1.0.7.
> >>>>>I've had some requests for adding PHPDocs style comments to the API.
> >>>>>Along with that 3 new function have been added
> >>>>>error() - returns an error code for the last error genterated
> >>>>>error_string() - returns a string with a description of the error
> >>>>>error_clear() - clears the last error
> >>>>>
> >>>>>Ryan
> >>>>
> >>>>
> >>>>Not to be incredibly anal, but the .php file should not have any
> >>>>newlines after the closing ?> tag -- this tends to mess with headers
> >>>>should it be included after headers have been sent. :(
> >>>>
> >>>>
> >>>
> >>>--
> >>>Ryan Gilfether
> >>>Software Engineer
> >>>http://www.gilfether.com
> >>>
> >>>
> >>
> >>
> >
> >
>
> --
> Ryan Gilfether
> Software Engineer
> http://www.gilfether.com
>