[rabbitmq-discuss] Flow Control

[Ben Hood]

Brian,

On Wed, Oct 22, 2008 at 2:14 AM, Brian Sullivan <bsullivan at lindenlab.com> wrote:
> [I am answering this thread, even though I think we have a bit of a split
> into two topics, and this one no longer has anything to do with jms
> support...  ;)   Responses inline.]

Sure, so I've changed the subject line and conveniently ignored JMS
tas a subject of discussion.

> I think the Channel.Flow command is exactly what I am looking for here.  Can
> I make the assumption that it will work in the case where there are NO
> subscribers (my "base case" scenario where the publisher is sending a ton of
> data, and I just don't have any clients currently reading it).  The
> publisher will simply get the Channel.Flow signal when the broker needs
> extra time to clean up messages it hasn't been able to throw away yet,
> correct?

The Channel.Flow command will be sent to all open channels and will
have the effect that message sending will be suspended until the
broker sends the pendant to allow the resumption of transmission. So
it doesn't matter when you have consumers or not. Furthermore, in one
of the previous posts I briefly discussed the possibility of
introducing a callback interface in the client so that you could take
action in an event driven fashion.

> Yeah, it is a bottleneck, but just for each host - and we are less worried
> about latency than we are about fault tolerance, because this is a logging
> system.  We currently have a similar system running, and want the hosts to
> be able to dump their logging messages easily (locally), then just have a
> process to pick this heterogeneous mix of logging messages and transmit them
> all to the exchange, on the appropriate topics.

Are you talking about some fast local broker that relays to a slower
*less-local* broker thus giving the producer the maximum amount of
bandwith in order to do a reliable fire and forget?

> I agree that egress flow is where our problem is (at least what I was
> expecting, and hopefully it's only one place...).  As long as the broker can
> send back a Channel.Flow command to a producer if one of the queues fills up
> the whole node, then we can back up and handle it when necessary, likely by
> upping the consumption rate.  We don't have a real need to do this
> dynamically right now - we just want to be able to detect the problem and
> address it via configuration at this point.

This would be doable with Channel.Flow.

> The main thing here is that we want to make sure the server doesn't crash if
> it gets overloaded, and that the behavior is predictable.From my tests
> somewhere earlier in this thread, I hit some wall where I saturated the
> broker and it got stuck at 200 msg/sec.  As long as the updated flow control
> works to keep the broker happy, then I think I am good.

This is the whole intention of the flow control implementation. In
your case, you were most likely seeing TCP-based flow control via back
pressure over the socket, but this is not something that we are going
to rely on given the message pipeline inside the broker. Hence the
upcoming Channel.Flow patch.

>> 4. Topics: I still haven't completely understood the rational behind
>> topic exchanges from the point of view of your application. As I have
>> indicated before, direct exchanges are more efficient that topics ATM,
>> but the sweet spot is going to depend on your app.
>>
>
> I think we got to an understanding on this one on the other thread.  Please
> let me know if it's still not clear why I want topic vs direct.  :)

Yep, that's been answered in the other thread.

HTH,

Ben