[rabbitmq-discuss] Usefulness of Channel.Flow with RabbitMQ 2.x.x

[A. MacLeod]

Thanks for the quick reply.

On Nov 9, 12:23 pm, Matthew Sackman <matt... at rabbitmq.com> wrote:
> On Tue, Nov 09, 2010 at 08:43:27AM -0800, A. MacLeod wrote:
> > Am I correct in concluding that a RabbitMQ 2.x.x broker will never
> > generate a channel.flow message, ever?
>
> Yes, you are.

Ok, cool.

> > I have also tried some experiments where I use something like
> > consumerChannel.flow(false) to stop flow on the consumer's channel.
> > However, when I try to reopen the flow by doing
> > consumerChannel.flow(true), my consumer instance (of a class derived
> > from DefaultConsumer) never receives any more messages.  Do I need to
> > re-issue consumerChannel.basicConsume(...) after I re-enable flow from
> > the consumer side?
>
> No, you shouldn't do. The Java client has a test for channel.flow in
> com.rabbitmq.client.test.functional.QosTests. If you can't make it work
> please let us know - it should all "just work".

Ok.  I will take a look at the client source code and adjust my
experimental code accordingly.  Probably I'm making some incorrect
assumptions about the sequencing and sync/async nature of various
calls.

> FWIW, the idea of the broker sending channel.flow to the client is a
> good one - it's sensible for the broker to be able to ignore just
> publishes amongst other methods on each given channel.
>
> Unfortunately, channel.flow is synchronous, so the broker has to wait
> for the client to respond (and send back the flow_ok) before it can
> start getting upperty should the producer continue to send messages. The
> problem here then is what timeout do you apply before you just start
> ignoring the producer anyway? If the client is only doing publishes
> anyway, you have absolutely no idea what the round trip time is.
> Furthermore, as we discovered when we tried to implement it, there's the
> possibility that the client _did_ respond and issue the flow_ok, but the
> broker was so overloaded it didn't notice it until after the timeout.
> Thus the client gets disconnected even when it did all the right things.
>
> Consequently, relying on TCP backpressure is pretty much the only
> sensible thing that can be done.

Sounds like a case of "fine in theory, but not so much in practice."
With such a fuzzy distinction between well-behaved and badly-behaved
clients, channel.flow starts to look pretty clunky.  From what I can
tell with the experimental code I've written, the TCP backpressure
works beautifully.

Thanks again for the info!