[rabbitmq-discuss] Handling Channel.Flow method

Wed Jan 6 17:28:42 GMT 2010

On 01/06/2010 05:07 PM, Chris Duncan wrote:
> Hi Gordon,
>
> On 6 Jan 2010, at 16:50, Gordon Sim wrote:
>
>> 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.
>
> I thought that the :nowait argument in the 0-8, 0-9 and 0-9-1 specs
> was what provides the ability to use synchronous methods in an
> asynchronous fashion. When I use the terms synchronous and
> asynchronous here I'm using them in the manner that the AMQP specs
> seem to use them; namely synchronous methods send a response to tell
> you whether they've succeeded and asynchronous ones don't. If :nowait
> is set to true doesn't that mean that the server will not send an -ok
> response?

Yes that is correct. My point was simply that sometimes you want to get 
a response (e.g. to confirm success) but you don't want to have to wait 
for that response before sending further requests (i.e. you don't want 
to be forced into strictly synchronous communication, but you do want to 
track success).