[rabbitmq-discuss] Unofficial guide to AMQP 1.0 PR3

[Rafael Schloming]

Jason Pellerin wrote:
> On Wednesday 05 May 2010 18:38:18 Michael Bridgen wrote:
> 
>> Flow control acts like a more fine-grained channel.flow for publishers,
>> and like basic.qos for consumers; in each case, the receiving side
>> issues *credit*, which the sending side uses up by transferring
>> messages.  To do something like a basic.get, a consumer issues a single
>> unit of *credit*, and waits for the single message to come in.
> 
> I hope I'm missing something, but this description jumped out at me as looking
> like AMQP 1.0 is going to include one of (IMO) 0-10's biggest mistakes.
> 
> As someone using messaging mainly in web applications, basic.get is the best
> thing in amqp. When response time matters, having a single command that polls
> for a message and returns immediately if one isn't present is incredibly
> useful. Replacing that with 2+ commands and replacing polling with waiting --
> ouch.

What Michael is describing above is correct, but not complete for the 
case you're interested in. To do a synchronous get you would also put 
the link in drain mode, and this would guarantee that your credit is 
consumed immediately, i.e. no waiting.

In the simple case this boils down to an interaction similar to 
basic.get. You send a flow frame (equivalent to basic.get ->), receive 
either a transfer (<- get-ok), or another flow frame indicating there is 
nothing available to transfer (<- get-empty).

This scheme has the significant added benefit that by issuing N units of 
credit rather than just one, you can use the same mechanism to poll in 
batches rather than just one message at a time.

While this is an evolution of the same flow control model first 
introduced in 0-10, I wouldn't be concerned over that as neither one 
requires you to substitute waiting for polling, and the number of 
frames/commands required is the same as for the equivalent basic.get 
interaction.

The flow control section of the transport spec includes examples of this 
and other cases if you're interested in more details.

--Rafael