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

[Matt Pietrek]

| Not really - that's more or less what's happening internally anyway.

Excellent. Well, not the part that there's no perf to be gained, but at
least I know what to expect.

| I'd clarify this as if you only allow one message in flight at a time,
they'll be no better or worse than transactions.

I assumed that, but thanks for explicitly clarifying this for future
readers of this thread.

On Fri, Feb 17, 2012 at 1:58 AM, Simon MacMullen <simon at rabbitmq.com> wrote:

> On 16/02/12 17:35, Matt Pietrek wrote:
>
>> 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
>>
>> In a mirrored queue scenario, is there any advantage to doing this vs.
>> using straight-up transactions?
>>
>
> Not really - that's more or less what's happening internally anyway.
>
> You'd have very slightly less network traffic (but no fewer round-trips).
>
> Later down the thread you say that "In a follow up, Simon MacMullen
> appears to agree that publisher confirms aren't ideal for us." - I'd
> clarify this as if you only allow one message in flight at a time, they'll
> be no better or worse than transactions.
>
> Cheers, Simon
>
> --
> Simon MacMullen
> RabbitMQ, VMware
>
> ______________________________**_________________
> rabbitmq-discuss mailing list
> rabbitmq-discuss at lists.**rabbitmq.com<rabbitmq-discuss at lists.rabbitmq.com>
> https://lists.rabbitmq.com/**cgi-bin/mailman/listinfo/**rabbitmq-discuss<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/20120217/15f7ea69/attachment.htm>