2

For publishers that have sent the confirm.select method, a literal reading of the RabbitMQ broker documentation suggests that message confirmation responses may be received by the client in an order different from the order that the original messages were published.

Can anyone verify that this is indeed the case? Or are messages always confirmed in the same order that they were received? If message confirmations can be received in a different order, what conditions are required for this to be the case?

Kevin Sitze
  • 8,029
  • 3
  • 16
  • 19
  • Note that I'm not interested in whether the confirmations were message acks or nacks but only the order in which these are received. – Kevin Sitze Mar 08 '17 at 19:00

1 Answers1

1

Can anyone verify that this is indeed the case?

Yes, messages could be confirmed in a different order

What conditions are required for this to be the case?

The basic rules for confirm are as follows:

  • an un-routable mandatory or immediate message is confirmed right after the basic.return;
  • otherwise, a transient message is confirmed the moment it is enqueued;
  • a persistent message is confirmed when it is persisted to disk or when it is consumed on every queue.

So, the possible reasons could be :

  1. Consider the case where persistent messages are not yet persisted to disc but forwarded to consumers. Since the messages are processed in an asynchronous manner, different messages may be ack'd by consumers in a different order and hence the order for confirms will change accordingly.
  2. TCP issues. The packets published by a publisher are not guaranteed to reach broker server in the same order. Hence, publisher cannot assume to receive them in the same order as published by it.
Rahul
  • 15,979
  • 4
  • 42
  • 63