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

Simone Busoli simone.busoli at gmail.com
Tue Oct 18 20:35:19 BST 2011


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" <mattgurney 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-discuss at lists.rabbitmq.com
> https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20111018/59f3b838/attachment.htm>


More information about the rabbitmq-discuss mailing list