[rabbitmq-discuss] Handling Channel.Flow method

Gordon Sim gsim at redhat.com
Wed Jan 6 17:16:49 GMT 2010


On 01/06/2010 06:55 AM, Alexis Richardson wrote:
> On Wed, Jan 6, 2010 at 4:40 AM, Chris Duncan<celldee at gmail.com>  wrote:
>>
>> I've also been reading the AMQP 0-10 specification. I have only skimmed it
>> before because I wasn't targeting a broker that implemented it. It contains
>> a section about transfer of responsibility that seems to deal with the
>> issues that I've been trying to address in my last two posts.
>
> Yes, that's how we designed it.  But, the goal of 0-10 was to provide
> a way to use acks and nacks for exactly-once delivery.  Your email
> only asks for an ack.  That's a bit easier and IMO better.

The need for some confirmation of publish is much wider than 
exactly-once delivery. That confirmation mechanism should also support 
asynchronous use if desired to avoid the performance impact Scott points 
out[*].

The 0-10 protocol doesn't really provide nacks per se. It has a 
message-release command which is useful when subscribers want to use 
prefetch and need to relinquish some of the messages delivered to them 
without killing the session.

[*] Perhaps of interest to mention that there was some disagreement 
within the amqp wg on whether -ok response to methods identified as 
synchronous by the 0-8 spec could be used asynchronously i.e. whether it 
was valid to send methods without waiting for the -ok and process 
receipt of those -ok response as they arrive in the other direction. 
Most (all?) of them aren't explicitly correlated, so were you to do that 
you would need to rely on the order of -oks matching the order of 
methods which if I recall correctly was the cause for concern at the time.




More information about the rabbitmq-discuss mailing list