Dustin wrote:
On Jan 25, 10:13 pm, Toru Maesaka <[email protected]> wrote:
I personally think that the behavior of not responding at all is okay
since this is for complementing the no-reply
I never particularly liked the no-reply mode for roughly the same
reason. I think specifically supressing any status, even the rare
failure will lead to hard-to-debug situations.
It was unavoidable in the text protocol because there was no way to
indicate which of several pipelined no-reply commands failed.
In the binary protocol, we can get both the efficiency gains of
sending commands that are likely to be successful, and still be able
to handle specific failure cases due to having opaques that can map
back to the requests.
I agree with Dustin on this one. Not only do we have the opaque to be
able to map it down to a specific request, the response also contains
the command code for the operation so a client author _could_ just log
the incident and throw away the packet (some clients may not have a good
way of returning such errors to the clients).
I vote for returning errors (this should be an easy patch :-))
Cheers,
Trond
