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