nsqd: some consumer commands do not return success responses

[tj]

There could be reasonable ways around this, but with the few commands that sometimes respond (on error) it makes writing clients that support command callbacks a little tricky. Ideally it's just a FIFO of callbacks, but we have to handle the case of RDY not receiving a response, but maybe receiving an error and so on.

Maybe always responding with OK would be more elegant? For now I'll probably just .emit() those.

[mreiferson]

@visionmedia - I understand your perspective, it is admittedly a bit inconsistent. Here's my answer to a recent ML post to provide some context (originally on https://groups.google.com/d/msg/nsq-users/VSxdPtw2ZmY/kmQJJhZe4wEJ but copied here):

This was done to reduce roundtrip overhead.

The only commands that do not return success responses are RDY/FIN/REQ/TOUCH. Notably, these are all commands used by consumers, only:

RDY - Any RDY command that fails is treated as a fatal error by nsqd, the client will be immediately and forcibly disconnected. There is no need for a success response.

FIN - A failed FIN command can only mean one of two things (neither considered fatal by nsqd) - that the MessageID you tried to FIN was invalid or that nsqd no longer considered you the “owner” of that MessageID. Either case is benign because it means the message was already delivered to another consumer. A client library can choose to log this as informational.

REQ - same as FIN with the additional failure case of specifying an invalid re-queue delay (which is treated as fatal by nsqd).

TOUCH - same as FIN/REQ

So, we’re left with a handful of cases where an error would be treated as fatal (and your connection forcibly closed) and a minor subset of cases where the error is purely informational.

Given that, it is unclear to me, for the domain of consumer commands in question, how success responses could improve responsiveness.

To summarize, for a client library's producer (where callbacks to commands are actually useful) every command does have a matching response.

For consumers there is really only one command (that a user of a client library would ever use) where you would actually want a callback, TOUCH. This is unfortunately a bit of a wart on the protocol. For all the other commands, IMO callbacks don't make sense (and any fatal error would end a session).

[tj]

Hmm yeah tough call, I can see how most would pretty much never occur in practice (failing on FIN/REQ etc). Oh well not a huge deal I should have read the docs better in the first place haha, I was wondering why we were having strange latency issues ;D

[mreiferson]

updated title for (hopefully) better searchability