mdelete and Cache::Memcached::delete_multi()

[dormando]

> 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.

So...

In production you're probably not likely to hit that too often. It's more
about errors that are sent after parsing. Those I think are a crux in the
noreply more than issues with wrong number of tokens.

On the other hand, making a change like that might adversely affect someone
with a slighty, but not entirey, broken configuration. Say they do something
braindead like occasionally send a bad command in the middle of some library,
but the rest of their code is right.

Could be jarring, hard to track down.

I'd take a patch as a compiletime option! close_on_parse_error. It'd be helpful
for those of us writing clients or developing new code against memcached.

-Dormando