Reputation: 712
From the Rabbitmq doc
Networks can fail in less-than-obvious ways and detecting some failures takes time. Therefore a client that's written a protocol frame or a set of frames (e.g. a published message) to its socket cannot assume that the message has reached the server and was successfully processed. It could have been lost along the way or its delivery can be significantly delayed.
Using standard AMQP 0-9-1, the only way to guarantee that a message isn't lost is by using transactions -- make the channel transactional then for each message or set of messages publish, commit.
I wonder why the publish-confirm or transaction is required to prevent the message lost for producer publish.
If the amqp "basic.publish" is called successful, the api return ok, why the message still possible lost?
Upvotes: 2
Views: 3197
Reputation: 1479
That snippet is talking about AMQP 0-9-1. RabbitMQ offers extensions to that protocol, one of which is Publisher Confirms. Publisher confirms are not part of the AMQP 0-9-1 standard itself.
If you get an "OK", or basic.ack, back then that is a Publisher Confirm. Once you have received that bacic.ack it means that the broker definitely received the message. But you could still "lose" the message at this point. If there are no queues bound to that exchange or there are no queues with a binding that matches the message, then the broker will discard the message. So although you received a basic.ack, the message is now lost.
So if you really want some guarantees you should use Publisher Confirms coupled with setting the Mandatory flag on the message. If you use this flag, then you will receive a basic.return (followed by a basic.ack) response from the broker if it received the message but could not route it to an exchange. Your application can then take appropriate measures.
Upvotes: 2