[rabbitmq-discuss] Handling Channel.Flow method

Wed Jan 6 17:39:05 GMT 2010

Hi Gordon,

On 6 Jan 2010, at 17:28, Gordon Sim wrote:

> 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).
>

I see your point sir :)

Regards,

Chris