[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