libmemcache 1.0.1

John McCaskey johnm at klir.com
Wed Dec 8 15:59:15 PST 2004


Ok, that doesn't really fix it either, please stand by for a proper
patch.

On Wed, 2004-12-08 at 15:32 -0800, John McCaskey wrote:
> 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


More information about the memcached mailing list