[rabbitmq-discuss] Handling Channel.Flow method

[Tony Garnock-Jones]

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