mdelete and Cache::Memcached::delete_multi()

Tomash Brechko tomash.brechko at
Fri Nov 16 11:01:52 UTC 2007

On Thu, Nov 15, 2007 at 22:32:24 +0300, Tomash Brechko wrote:
> Currently 'noreply' will still send the error if the command has wrong
> number of tokens, and thus no attempt is made to parse it (though I
> could parse it, I think that wouldn't be right).  To help this a bit
> we may add a startup option to the server, 'close_on_error', and use
> it for some errors that should never be ignored, so the error
> condition won't go unnoticed.

It seems like 'noreply' is not the only command that is not immune to
syntax errors.  Recently the following test was added:

  # cas empty
  print $sock "cas foo 0 0 6 \r\nbarva2\r\n";
  is(scalar <$sock>, "ERROR\r\n", "cas empty, throw error");

But see what's happens:

  - server reads "cas foo 0 0 6 \r\n".  Wrong number of tokens (CAS
    value missing), server can't parse command reliably, sends ERROR.

  - server reads "barva2\r\n"!  No such command, server sends another
    ERROR (and you can imagine what would happen if this data would by
    accident be "flush_all\r\n", for instance).

It's the same transparent proxy problem.  Can't parse -> can't
reliably swallow the command.  Should we made close-on-error behaviour
mandatory for parse errors?  This is reasonable, since it's very
unlikely that any client out there has logic to recover from self
malformed commands.

   Tomash Brechko

More information about the memcached mailing list