memcached server loses set command when followed by quit

[Kevin Dalley]

By the way, thanks for the suggestions, from long ago.

The changes you suggested solved the problem of missing commands.


On Mon, 2008-01-28 at 20:58 +0300, Tomash Brechko wrote:
> On Mon, Jan 28, 2008 at 09:38:19 -0800, Kevin Dalley wrote:
> > 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.
> 
> Yep, the replies you haven't yet read may prevent the server from
> processing following commands (because there's no room to write their
> replies to, all outgoing buffers are full), so the client should
> always read everything to effectively "push" all pending non-blocking
> requests.
> 
> On a side note, I recently saw the benchmarks of upcoming
> Cache::Memcached::LibMemcached module (it uses libmemcached).  It had
> reported "more than a million requests per second" speed in
> non-blocking mode, which looked just insane to me (C::M::F is much
> slower in its nowait mode, I'm biased person :)).  However, it turned
> out that at least for C::M::LibMemcached 0.000006 + libmemcached 0.13
> _nothing_ is being sent to the server during the benchmark, hence such
> great noop speed.  It still sent nothing when I tried to execute get
> after a sequence of sets.  Maybe the patches that you mentioned would
> fix this?..
> 
>