[rabbitmq-discuss] Channel Flow

[Ben Hood]

Barry,

On Mon, Nov 3, 2008 at 3:07 PM, Barry Pederson <bp at barryp.org> wrote:
> Hmm, I've been pondering this for a day now, and don't think the client as
> it is structured now could really deal with flow control.  I think
> something's going to have to give - either pure single-threadedness, SSL
> support using the stock Python libraries, or SSL support with Python
> versions less than 2.6
>
> I think the easiest thing to do would be to have an optional mode that made
> use of another thread.  That could also allow for some other things like
> timeouts when receiving.

Sure, that is what the Java client does.

An alternative option that may avoid using another thread is to fail
fast, i.e. notify the app that message that is requesting to send
won't/can't be sent, e.g. by raising an exception or by using some
special return value that the app would have to test.

> In the meantime, anyone have thoughts as to what should happen on the client
> when the broker calls for pause...should the client buffer messages locally?
> or block and wait for a resume from the broker?  I suppose ideally there'd
> be options for both, but if you had to choose..?

I would orientate my decision around the transfer of responsibility.
As Martin points out, if you do buffer things in the client, you
should make it clear to higher level code that you are doing so, so as
not to give the application the impression that the broker has
accepted responsibility for the message.

Another thing that I would consider is the role of back pressure in
this scenario. By issuing the channel.flow command, the broker is
blocking the client - maybe you would want to propagate this
resistence back to the calling app.

HTH,

Ben