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

Wed Oct 19 11:25:38 BST 2011

https://groups.google.com/d/topic/rabbitmq-discuss/3gfagTaY97k/discussion

-----Original Message-----
From: rabbitmq-discuss-bounces at lists.rabbitmq.com [mailto:rabbitmq-discuss-bounces at lists.rabbitmq.com] On Behalf Of Matt G
Sent: mercoledì 19 ottobre 2011 12:16
To: rabbitmq-discuss at lists.rabbitmq.com
Subject: Re: [rabbitmq-discuss] Highest Reliability simple publish to a queue

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
_______________________________________________
rabbitmq-discuss mailing list
rabbitmq-discuss at lists.rabbitmq.com
https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss

_________________________________________________________________________________________________________________
Questo messaggio è da intendersi esclusivamente ad uso del destinatario e può contenere informazioni che sono di natura privilegiata, confidenziale
o non divulgabile secondo le leggi vigenti. Se il lettore del presente messaggio non è il destinatario designato, o il dipendente/agente responsabile
per la consegna del messaggio al destinatario designato, si informa che ogni disseminazione, distribuzione o copiatura di questa comunicazione è 
strettamente proibita anche ai sensi del decreto legislativo 196/03 . Se avete ricevuto questo messaggio per errore, vi preghiamo di notificarcelo
immediatamente a mezzo e-mail di risposta e successivamente di procedere alla cancellazione di questa e-mail e relativi allegati dal vostro sistema.
_________________________________________________________________________________________________________________
This message is intended only for the use of the addressee and may contain information that is privileged, confidential and exempt from 
disclosure under applicable law. If the reader of this message is not the intended recipient, or the employee or agent responsible for delivering the 
message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly 
prohibited. If you have received this e-mail in error, please notify us immediately by return e-mail and delete this e-mail and all attachments from 
your system.
_________________________________________________________________________________________________________________