[rabbitmq-discuss] Highest Reliability simple publish to a queue
simon at rabbitmq.com
Wed Oct 19 11:43:18 BST 2011
On 18/10/11 15:16, Matt G wrote:
> So far it appears to me that I should use the following, can you
> review my list and edit as necessary:
> Durable exchange
> Durable queue
> Persistent message (Delivery Mode = 2)
> Mandatory message
> Model/Channel.ConfirmSelect& Model.WaitForConfirmsOrDie();
Sure, makes sense. The only thing that's unusual in your case is the use
of mandatory in order to test if the queue has been unbound. Normally I
would say "well, don't unbind it then", this is not the sort of thing
that will happen spontaneously :)
If you know the name of the queue you want to publish to then an
alternative would be to publish via the default exchange. Since queues
are always implicitly bound to the default exchange you could lose the
use of "mandatory" there. Assuming you are not going to delete the queue
> I also setup event handlers BasicAcks, BasicNacks& BasicReturn.
> If for testing purposes I unbind the queue from the exchange, and send
> a single message, I get a BasicAck and a BasicReturn(NO_ROUTE) back,
> however the Model.WaitForConfirmsOrDie() returns without error.
Yes, WaitForConfirmsOrDie() is just counting acks aka confirms.
Basic.return is a different thing. RabbitMQ will ensure that by the time
you get an ack back, you will have received a basic.return if one was
going to be sent.
> seems inconsistent in that my message has been lost as there is no
> queue bound to the exchange and I have specified mandatory and every
> persistent option I can find. Is this correct, or am I doing something
> wrong? Do I need to do/check both (WaitForConfirms& BasicReturn event
> msg) to be sure the message was successfully delivered to the queue?
The meaning of a confirm is "RabbitMQ has taken responsibility for the
message, and handled it in whatever way it was meant to be handled". If
that means dropping it on the floor as unrouted then so be it - the
assumption is that the routing is set up how you wanted it. manadtory /
basic.return then adds on top of that the ability to check that a
message got routed somewhere.
> Where is the documentation for API calls which are not documented in
> the API doc, an example is WaitForConfirmsOrDie, but there are many
Hmm. The HTMLdoc for those is not coming through. Looks like invalid
XML. Will file a bug.
It's in the source:
> I read one of the other posts directing people away from transactions
> and towards the Model/Channel.ConfirmSelect&
> Model.WaitForConfirmsOrDie() model, so I have not investigated
> What about connection heart beating? I know from my experience with
> other products HB's are good way to keep the client and server in-sync
> and aware if the other party has gone off line. Should I overwrite the
> default which appears to be no heartbeats?
Yes, that would be reasonable. Depends on whether you're more concerned
about a short connectivity loss killing your connections or a long one
More information about the rabbitmq-discuss