memcached server loses set command when followed by quit

[Kevin Dalley]

Thanks for the answer.  I have mixed feelings on the design.

On the one hand, the server does have state.  If a key is set, that key
is available to all future clients.  Even if the client is not
listening, the server should be modified.

However, it is easy to modify the client so that it tries to read the
responses before giving up.  And notes the closure of the socket after
"quit\r\n" is sent, perhaps eventually giving up.

Right now, I think that the quit command should read the socket until
EOF is received, perhaps sucking out a large number of responses to
previous requests which will be ignored by the client.


On Mon, 2008-01-28 at 10:32 +0300, Tomash Brechko wrote:
> 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).
> 
>