mdelete and Cache::Memcached::delete_multi()
dormando at rydia.net
Mon Nov 19 00:24:54 UTC 2007
> 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.
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.
More information about the memcached