[rabbitmq-discuss] Performance of "blocking publisher-confirms" vs. transactions

Thu Feb 16 21:08:12 GMT 2012

Hi Matt, I've gone through the old thread very quickly so forgive me if I'm
missing something. Your first sentence leaves me with some doubts:

As I've detailed in other posts to this DL (http://bit.ly/zf6sKC), we have
> situation where straightforward publisher-confirms aren't appropriate in
> our scenario. We need to know the broker has received the message, and we
> have to assume our client can die at any moment, so retransmitting messages
> is not an option for us.
>

Publisher confirms guarantee that the broker has taken care of the message
and it has been either delivered to a queue or to a consumer. This is a
strong delivery guarantee, even if the client dies. Coupled with persistent
messages and durable exchange/queues, it guarantees at-least-once delivery.
Can you describe why you think publisher confirms are not appropriate in
your scenario?

> What I'd like to know is: Is there any benefit to creating our own
> "blocking publisher-confirm publishing"? That is, we'd do the following:
>
> Publish a single message
> Block on an event 'X'
> When the publisher confirm comes in, signal 'X'
> Return from the publish call
>

If you happen to be using the .NET API this is already implemented, the
WaitForConfirms and WaitForConfirmsOrDie on the IModel interface provide
this behavior.

> In a mirrored queue scenario, is there any advantage to doing this vs.
> using straight-up transactions?
>
> Matt
>
> p.s. I realize in the above pseudocode that multiple threads would be
> necessary - One to block and the other to listen for the publisher-confirm.
>
>
> _______________________________________________
> 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/20120216/6d6f4ed0/attachment.htm>