[rabbitmq-discuss] Performance of "blocking publisher-confirms" vs. transactions
simone.busoli at gmail.com
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
> 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
> In a mirrored queue scenario, is there any advantage to doing this vs.
> using straight-up transactions?
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the rabbitmq-discuss