Memcache CAS

[Dustin Sallings]

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