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

Wed Oct 19 11:16:29 BST 2011

Thanks Simone, Which of my six questions do you think I can find the
answer for in the archives, I am not finding the answers I am after.
If anyone else can have a quick look at my questions it would be much
appreciated, I am a new comer to RMQ and I think my questions may be
simple for anyone with some experience.

Our requirement is to reliably persist the web service payload into a
RMQ as per the "Responsibility Transfer" pattern on page 21 of the
RabbitMQ .Net Client Library User Guide. I have implemented the
options as described in that section, I am just checking if there is
anything else I need.

The lack of any documentation on WaitForConfirmsOrDie() bothers me,
currently I am assuming that it blocks program execution until all
confirm/nack/ack/reply due to the Model/Channel.ConfirmSelect are
received. But I can not find this documented anywhere. I mean, is that
what it does, how long does it wait before the "Die" and what happens
when it "Dies" etc.

On Oct 19, 6:35 am, Simone Busoli <simone.bus... at gmail.com> wrote:
> Hi Mike, this has been asked several times on the list recently, I think you
> will find your answer by searching the archives.
> By the way, I am curious why you want to do everything synchronously as you
> wouldn't need Rabbit for that.
> On Oct 18, 2011 4:32 PM, "Matt G" <mattgur... at gmail.com> wrote:
>
>
>
>
>
>
>
> > Hi,
>
> > I have a simple scenario where a web service will receive a http
> > request and I would like to insert the request into a queue, and be
> > sure the message has arrived on the queue before synchronously
> > responding to the http request.
>
> > Ideally I would like RMQ to "guarantee" that the message has been
> > delivered to the queue. I have been using IBM MQ and TIBCO EMS (JMS
> > implementation) for many years, but I am new to RMQ.
>
> > Performance is not an issue, the volume will not be an issue.
>
> > I am using c# with latest AMQ versions on Windows and Linux.
>
> > 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();
>
> > 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. 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?
>
> > Where is the documentation for API calls which are not documented in
> > the API doc, an example is WaitForConfirmsOrDie, but there are many
> > others?
>
> > 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.
>
> > 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?
>
> > I am not currently using any of the helper/pattern classes, would one
> > of those be suitable for my requirements for high reliability.
>
> > Thanks,
> > Matt.
> > _______________________________________________
> > rabbitmq-discuss mailing list
> > rabbitmq-disc... at lists.rabbitmq.com
> >https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
>
>
>
> _______________________________________________
> rabbitmq-discuss mailing list
> rabbitmq-disc... at lists.rabbitmq.comhttps://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss