[rabbitmq-discuss] Handling Channel.Flow method

Thu Mar 4 20:39:09 GMT 2010

Hi Tony,

Thanks for the response. Sorry I've taken a while to reply.

On 17 Feb 2010, at 06:51, Tony Garnock-Jones wrote:

> Chris Duncan wrote:
>> Transactions may give me what I want but I don't think that I  
>> should be
>> enforcing the use of transactions in my client library just so  
>> that it
>> will handle Channel.Flow methods properly.
>
> The way channel.flow works, if I understand it correctly, is that the
> server sends channel.flow, the client receives it, and eventually  
> sends
> a channel.flow-ok in response, which acts as a promise not to send any
> more content until another channel.flow lets it continue. The key word
> is "eventually", meaning that the server has to give it a little  
> slack,
> and sometimes quite a lot of slack, heuristically.
>
> Clients must be permitted to continue sending content frames, and
> servers should probably go to reasonable lengths to handle such  
> content
> frames, after the channel.flow is sent and before the channel.flow- 
> ok is
> received by the server, simply because of the separation between  
> the two
> parties.
>
> If you defer emitting your channel.flow-ok until all in-progress
> channel.publish operations have cleared the line, then you should be
> cool. There should be no need to interact with the transaction  
> machinery
> at all. Your client library API should reflect the fact that the  
> client
> has been asked and has promised to be silent, perhaps by indicating
> failure somehow for *subsequent* publish operations after the
> channel.flow is received.
>
> Um. I'm not sure that was the clearest explanation of what I mean :-)
> I'm basically trying to get at the fact that you don't have to stop
> sending content until you've sent the channel.flow-ok, and you can use
> that to make a clean switch from XON to XOFF state, more or less. Does
> that make sense?
>
> Tony
>

It was a clear explanation and does make very good sense.

Regards,

Chris