libmemcache 1.0.1

[John McCaskey]

Ok, so I believe I've fixed the issue.

The problem looked to be that the only check that would cause a goto to
get_more_bits, as if there as no \n in the retrieved buffer, yet the
mc_fetch_cmd code was assuming not just that the first line was
complete, but all the data had been completely read as well.

As such I made mc_get_line check if the amount of data read on the
socket == the max allowed, and if so try to read some more, so that it
will always read in the whole response at once.

I also noticed some issues with the addresses not all getting set after
the ReAlloc call, which would work fine if your implementation happened
to not change the address, but would fail otherwise (failed for me under
linux 2.4 and 2.6). So I fixed that, and finally the code for
determining the location of the newline had to be updated to account for
the fact that the newline might not be in mc->read_cur, but ealier in
mc->cur since I read everything at once.

I don't think this has any negative performance implication as the whole
response is going to have to be read before much can be done anyway, but
it probably could be optimized to go back to how it was before, but
modify mc_fetch_cmd to call mc_get_line again before attempting to set
res->val where it now falsely assumes that the second line was already
completed.

See attached patch file.


On Tue, 2004-12-07 at 14:02 -0800, John McCaskey wrote:
> Sean,
> 
> Sorry to be such a pain :)  But... it looks like if we store values >
> 1024 bytes (actually something like 700 some...), that we get a protocol
> error for the \r\n not being found, and no data returned.
> 
> Looks like the detection of larger responses and allocation of a larger
> buffer is broken?
> 
> I'm going to be looking into this more this afternoon, but I wondered if
> you had any imediate ideas or known issues in this area.
> 
> Thanks again,
> 
> On Tue, 2004-12-07 at 11:53 -0800, Sean Chittenden wrote:
> > > http://people.FreeBSD.org/~seanc/libmemcache/
> > >
> > > Notes:
> > >
> > > 	*) libmemcache.h has been renamed memcache.h
> > > 	*) Fixes a few bugs with mc_aget()
> > > 	*) Moved from strlen() to sizeof() for additional compile time 
> > > optimizations
> > > 	*) Installing memcache.h now on 'make install'
> > 
> > errr...
> > 
> > 	*) The refresh API slipped through and is available in this release.
> > 
> > Please don't use the refresh commands as that API isn't available in 
> > the stock memcached(8) distribution.  Dig through the archives if you 
> > want the patch, however.
> > 
> > -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: oversized_values.patch
Type: text/x-patch
Size: 1262 bytes
Desc: not available
Url : http://lists.danga.com/pipermail/memcached/attachments/20041207/ef26112f/oversized_values.bin