libmemcache 1.0.1

[John McCaskey]

It seems I didn't test my patch for long values enough ;)

Each time the read() command was reading more and more (first pass 1024,
second 2048, ...) where as each time it should read 1024.  This was
caused by my not updating the mc->cur to mc->read_cur in one of the
calculations.

This then also needed to get updated in the check to see if
rb=max_read_allowed.

See attached second patch which is just two quick changes of mc->cur ->
mc->read_cur.  This patch is against 1.0.2 as I haven't had a chance to
take a look at the 1.1.0rc1 yet today, but I suspect you can convert it
over very easily.

Sorry for the mistake!  I'm going to take a detailed look at the binary
protocol stuff tommorow as well, looks good at first glance.


On Tue, 2004-12-07 at 17:12 -0800, Sean Chittenden wrote:
> >>> Ok, so I believe I've fixed the issue.
> >>
> >> Fix incorporated into 1.0.2.
> >>
> >> http://people.FreeBSD.org/~seanc/libmemcache/
> >>
> >> This release also fixes some miscellanea for FreeBSD's bento cluster,
> >> but no one here should care too much.
> >
> > Excellent!
> 
> Let me know if you dig up anything, but I think this release fixes all 
> known issues.  The bug you provided a patch for was known, but I hadn't 
> had time to figure it out yet.
> 
> >> Ah, yeah.  Good catch.  The worst case scenario being that the 
> >> response
> >> was exactly the same as the number of bits coming in.  I don't think
> >> there's any way around this for now.  Text protocols suck (*nudges 
> >> Brad
> >> to send feedback on binary protocol spec* [-: ).
> >>
> > Yeah, I thought about the fact that the response might be exactly the
> > same size.  The only thing that seemed possible was to check for the \r
> > \nEND\r\n sequence, and then not goto get_more_bits, but checking that
> > every single time when the likelihood of an exact size match is very 
> > low
> > seemed like a definate loss.
> 
> Nevermind it won't work in the multi-get request case.  :)
> 
> > I agree about the binary protocol, text ones are nice because its easy
> > to manually test, but for real production high performance work it 
> > would
> > be preferable to get away from that I think.
> 
> Exactly.  -sc
> 
-- 
John A. McCaskey
Software Development Engineer
Klir Technologies, Inc.
johnm at klir.com
206.902.2027
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fix_johns_bad_patch.patch
Type: text/x-patch
Size: 952 bytes
Desc: not available
Url : http://lists.danga.com/pipermail/memcached/attachments/20041208/ae51ddd3/fix_johns_bad_patch-0001.bin