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

[Matt G]

Thanks Simon, that answers all my questions.

Matt.

On Oct 19, 9:43 pm, Simon MacMullen <si... at rabbitmq.com> wrote:
> 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/pr...
>
> > 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
> _______________________________________________
> rabbitmq-discuss mailing list
> rabbitmq-disc... at lists.rabbitmq.comhttps://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss