Behavior of channels in "confirm" mode with RabbitMQ

 

I've got some trouble understanding the confirm of RabbitMQ, I see the following explanation from RabbitMQ:

Notes

The broker loses persistent messages if it crashes before said messages are written to disk. Under certain conditions, this causes the broker to behave in surprising ways. For instance, consider this scenario:

  • a client publishes a persistent message to a durable queue

  • a client consumes the message from the queue (noting that the message is persistent and the queue durable), but doesn't yet ack it,

  • the broker dies and is restarted, and

  • the client reconnects and starts consuming messages.

    • At this point, the client could reasonably assume that the message will be delivered again. This is not the case: the restart has caused the broker to lose the message. In order to guarantee persistence, a client should use confirms. If the publisher's channel had been in confirm mode, the publisher would not have received an ack for the lost message (since the consumer hadn't ack'd it and it hadn't been written to disk).

    Then I am using this http://hg.rabbitmq.com/rabbitmq-java-client/file/default/test/src/com/rabbitmq/examples/ConfirmDontLoseMessages.java to do some basic test and verify the confirm, but get some weird results:

  • The waitForConfirmsOrDie method doesn't block the producer, which is different from my expectation, I suppose the waitForConfirmsOrDie will block the producer until all the messages have been ack'd or one of them is nack'd.
  • I remove the channel.confirmSelect() and channel.waitForConfirmsOrDie() from publisher, and change the consumer from auto ack to manual ack, I publish all messages to the queue and consume messages one by one, then I stop the rabbitmq server during the consuming process, what I expect now is the left messages will be lost after the rabbitmq server is restarted, because the channel is not in confirm mode, but I still see all other messages in the queue after the server restart.

    • Since I am new to RabbitMQ, can anyone tells me where is my problem of the confirm understanding?

    My understanding is that "Channel Confirmation" is for Broker confirms it successfully got the message from producer, regardless of consumer ack this message or not. Depending on the queue type and message deliver mode, see http://www.rabbitmq.com/confirms.html for details,

    the messages are confirmed when:

  • it decides a message will not be routed to queues (if the mandatory flag is set then the basic.return is sent first) or
  • a transient message has reached all its queues (and mirrors) or
  • a persistent message has reached all its queues (and mirrors) and been persisted to disk (and fsynced) or
  • a persistent message has been consumed (and if necessary acknowledged) from all its queues

    • Old question but oh well..

    I publish all messages to the queue and consume messages one by one, then I stop the rabbitmq server during the consuming process, what I expect now is the left messages will be lost after the rabbitmq server is restarted, because the channel is not in confirm mode, but I still see all other messages in the queue after the server restart.

    This is actually how it should work, IF the persistence is enabled. If the server crashes or something else goes wrong, the messages cannot be confirmed, and thus, won't be removed from the queue.

    Messages will only be removed from the queue if they are confirmed to be handled, or the broker didn't yet write it to memory or disk before the server crashed.

    Confirming and acknowledging can be set off if wanted, and the producer won't be waiting for the acks. I cannot find the exact command for it right now, but it does exist.

    More on the acks and confirms: https://www.rabbitmq.com/reliability.html

    链接地址: http://www.djcxy.com/p/10160.html

    上一篇: Windows Phone 7 Mango的FTP客户端？

    下一篇: RabbitMQ在“确认”模式下的通道行为