[rabbitmq-discuss] Highest Reliability simple publish to a queue

[Simon MacMullen]

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
> ExchangeType.Direct
> 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 
in question...

> 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.

> This
> 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?

Yes.

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
> others?

Hmm. The HTMLdoc for those is not coming through. Looks like invalid 
XML. Will file a bug.

It's in the source:
http://hg.rabbitmq.com/rabbitmq-dotnet-client/file/rabbitmq_v2_6_1/projects/client/RabbitMQ.Client/src/client/api/IModel.cs#l320

> 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
> transactions.

That's reasonable.

> 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 
going undetected...

Cheers, Simon

-- 
Simon MacMullen
RabbitMQ, VMware