[rabbitmq-discuss] Handling Channel.Flow method
celldee at gmail.com
Thu Mar 4 20:39:09 GMT 2010
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
> 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
> 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
> 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
> 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
> at all. Your client library API should reflect the fact that the
> 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?
It was a clear explanation and does make very good sense.
More information about the rabbitmq-discuss