dustin at spy.net
Mon Sep 17 07:23:13 UTC 2007
On Sep 17, 2007, at 0:12, Chris Goffinet wrote:
> 1) For :1113 I noticed if I added the item_remove diff like you
> suggested, it ends up returning the memory identifier of the new
> variable that is always the same in memory vs address of actual
> item pulled from item_get. Suggestions to fix? Try it yourself,
> when you use the same itmp variable on it and set a few items over
> and over again. It will usually always be same memory address (even
> if data changes).
I suppose that makes sense with the slab allocator. Perhaps the
memory address is not adequate and a counter would be more
appropriate after all.
> 2) Yeah I expanded item_alloc because the way memcache reads
> through the loop of data sent. Originally I did it the way I sent
> you, but ran into an issue with existing clients. I noticed that
> memcached would throw an error right when memcache read the cas
> command (which is OK..). But all of our commands (add,replace,set)
> wait until complete_nread occur before returning either STORED/
> NOT_STORED to be compatible with existing clients.
Draining the input buffer does seem like the right thing to do. I
think it's somewhat important to be able to distinguish between an
allocation failure, match failure, and and a missing record.
In my binary protocol implementation, I implemented a command that
could transmit an error back to the client and sink a chunk of data
whose size is known ahead of time. I use it for unknown commands,
failing sets, etc... so I can basically do this when a cas comparison
write_bin_error(c, ERR_EXISTS, vlen);
More information about the memcached