RabbitMQ subscriber sending message back onto RabbitMQ queue?

Question

I would appreciate your thoughts on this.

I have a node app which subscribes to a RabbitMQ queue. When it receives a message, it checks it for something and then saves it to a database.

However, if the message is missing some information or some other criteria is not yet met, I would like the subscriber to publish the message back onto the RabbitMQ queue.

I understand logically this is just connecting to the queue and publishing the message, but is it really this simple or is this a bad practice or potentially dangerous?

Thanks for your help.

when the message is missing something, then publish to the same queue which receive message from it? If so, you can set the `autoack` is `false`, and the message is removed from queue unless you give ack to it. then if the message is missing something, no ack, and this message will stay in queue without be deleted. If the message is goo, give ack to this queue, then this message will be remove from queue. — zangw, Mar 05 '16 at 14:18
@zangw yes publish to the same queue it got the message from. (it's hard to explain, but there's a timing element to the messages, so it might be valid in 5 minutes rather than now). — Tom Brock, Mar 05 '16 at 14:21

score 1 · Answer 1 · answered Mar 05 '16 at 14:38

As I point out in the comment, When you create connection with queue, and set autoAck = true, to enable message acknowledge. The message in the queue will be deleted until receive acknowledge.

When the received message meets requirement, then send ack message to this queue, and this message will be deleted from queue. Otherwise, no ack message is sent to queue, this message will stay in the queue.

As for you mentioned in comment, the valid process may take 5 minutes, just set the send ack message as callback function of validation function.

score 0 · Answer 2 · edited May 23 '17 at 11:50

In your question, you describe two criterion for when a message may not be processed:

if the message is missing some information or

some other criteria is not yet met

The first of these appears to be an issue with the message, and it doesn't seem that it makes much sense to re-queue a message that has a problem. The appropriate action is to log an error and drop the message (or invoke whatever error-handling logic your application contains).

The second of these is rather vague, but for the purposes of this answer, we will assume that the problem is not with the message but with some other component in the system (e.g. perhaps a network connection issue). In this case, the consuming application can send a Nack (negative acknowldegement) which can optionally requeue the message.

Keep in mind that in the second case, it will be necessary to shut down the consumer until the error condition has resolved, or the message will be redelivered and erroneously processed ad infinitum until the system is back up, thus wasting resources on an unprocessable message.

Why use a nack instead of simply re-publishing?
This will set the "redelivered" flag on the message so that you know it was delivered once already. There are other options as well for handling bad messages.

RabbitMQ subscriber sending message back onto RabbitMQ queue?

2 Answers2