memcached server loses set command when followed by quit

Tomash Brechko tomash.brechko at gmail.com
Mon Jan 28 07:32:13 UTC 2008


On Sun, Jan 27, 2008 at 10:34:43 -0800, Kevin Dalley wrote:
> "set foo 0 0 16\r\nwhen we sanitize\r\nquit\r\n"
> 
> followed by a new connection with "add foo 0 0 16\r\nwhen we sanitize\r
> \n"
> 
> I expect that the set will succeed, followed by a connection closed,
> then an unsuccessful add. Sometimes, this works, but often the set
> disappears.

I hit the same problem while developing nowait mode for
Cache::Memcached::Fast, however I think that the server logic is
correct, and it's the clients that should be made aware of this
feature.  Here's what happens: originally memcached protocol was meant
to work in a request-reply format.  Thus the implementation assumes
that you would read the reply before sending the next request.  In
try_read_network() (memcached.c) it reads as mush data from the
network as it can until getting EAGAIN.  And if memcached would get
EOF then, it would simply close the connection discarding everything
read so far.  Indeed, there's no point to execute any (possibly
partial) command if no one is waiting for the outcome (the client
could've died).


-- 
   Tomash Brechko


More information about the memcached mailing list