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
fails:
write_bin_error(c, ERR_EXISTS, vlen);
--
Dustin Sallings
