[rabbitmq-discuss] Channel Flow
Barry Pederson
bp at barryp.org
Mon Nov 3 15:07:14 GMT 2008
Ben Hood wrote:
> Hey Barry,
>
> One of the features in the next Rabbit release (ETA within a few
> weeks) is the implementation of the Channel.Flow command.
>
> This will announced properly in due course, but we have had some
> non-list interest on this subject from people using py-amqplib and
> would like to be able to use the Channel.Flow command with it.
>
> So this is just a heads up to let you know that you may be getting a
> new feature request.
>
> Essentially Channel.Flow is a reverse RPC that the client should react
> to by pausing the sending of any content carrying commands until the
> broker notifies it that sending can be resumed.
>
> This functionality exists for the server in the branch called 19468
> and in the java client in branch 19559.
>
> I'm not quite sure what implication this has for a non-blocking
> client, hence I am kicking of a discussion.
>
> Ben
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.
Don't think I'll get a chance to work on this in the next few days (busy
with election stuff), but I'll keep pondering it.
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..?
Barry
More information about the rabbitmq-discuss
mailing list