mdelete and Cache::Memcached::delete_multi()

[Tomash Brechko]

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