[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