PHP client's _load_items (was: memcached in freebsd)

[Brad Fitzpatrick]

Yeah, the _load_items function in the PHP client is kinda scary.

There's no way to treat a socket like a stream in PHP?  The command
sending in _load_items is good, but the parsing (especially not
respecting END\r\n on any "line") is wrong.  It'd be so much easier if
you could read a line or a block at a time.  Then you wouldn't have
to remember so much state.

Unrelated, that file's in need of some tabs vs. spaces cleanup.  Go one
way or the other and be consistent, or at least add all the emacs/vim
hints at the top/bottom, so people's editors know how wide you thought
your spaces were.

Ryan, in the future feel free to post diffs to the list, rather than
tarballs to me directly, then everybody can get access to things when I'm
away for a few hours, and it's easier to read a diff, too.  If you need
help with cvs and/or making diffs from cvs, email me off-list.

- Brad


On Sun, 10 Aug 2003, Anatoly Vorobey wrote:

> Brion Vibber wrote on Sun, Aug 10, 2003 at 02:42:38AM -0700:
> > On further investigation, I note two things:
> >
> > a) The "_load_items(): Failed to recieve valid header!" is what I get
> > anytime I ask for data that isn't available, and seems to be normal.
>
> Well, if some data you asked for isn't available, it's _not_ an error,
> and you don't fail to receive a valid header, so something strange is
> going on. A cursory look at the client's source (I don't really know any
> PHP) seems to indicate that the client makes some unwarranted
> assumptions. I _think_ it only recognises the "END\r\n" line which
> finishes any batch of data a server sends when this line comes in the
> same buffer (as a result of the same read call) with some previous data
> for some key. As a result, when the server fails to match any keys, and
> only sends "END\r\n" (correctly, according to the protocol), the client
> thinks it's an error. This by itself may be harmless, but I think that
> more serious errors could occur if the "END\r\n" doesn't come in the
> same IP packet as the rest of server's reply (say if the reply is too
> large to fit in one packet) and subsequently arrives via a separate
> read request. This logic should be fixed (there shouldn't be any
> assumptions about how data is separated across read/write calls).
>
> > D'oh! Looks like relative expiration times are a new feature of
> > 1.1.7/1.1.8, and 1.1.6 expects either 0 or a full Unix timestamp.
>
> That's correct (don't use 1.1.7, it has an embarrassing bug related to
> this very feature).
>
> --avva
>
>