[rabbitmq-discuss] jms support

[Ben Hood]

Brian,

On Mon, Oct 20, 2008 at 5:09 PM, Brian Sullivan <bsullivan at lindenlab.com> wrote:
> We do have certain high-volume topics that we would like to be able to not
> worry about buildup - if we aren't running the consuming applications, I
> would expect there to be very little load on the system.  If I understand
> you correctly, I can get flow control if I have an active subscription.

Well not exactly. There is a command in AMQP called Channel.Flow which
is essentially a reverse RPC - the broker requests the client to
suspend sending any messages until such a time that the broker
notifies the client that it can resume sending messages. This gives
the broker a chance to process a backlog and thus prevents any
overflow. The current released version of Rabbit does not implement
this command, we are working on it at the moment and should be
released in the near future (but as always, no concrete ETA).

>  What I want to protect us against is slowing down of the entire system
> because of a spammy topic or two - we'd really like to have the ability to
> turn off consumption of that topic should things go haywire (either on
> message publication, or falling behind on the consumption of other feeds).

To prevent backlog you would ideally want to decrease production (e.g.
by using Channel.Flow) or increase consumption (e.g. by adding more
consumers). I don't think you would want to decrease consumption.

>  The goal we have is to publish everything (ie, not turn off certain topics
> when we have a problem), and manage the load on the server via subscriptions
> and clustering.  Note that our publishing side has all intermixed topics -
> we have applications log all messages to a single place on a host, then we
> simply use that as a transmission buffer.  The benefit there is that we have
> a central place to store the queue of messages to be sent and can manage
> buffering there.  The downside is that flow controlling a single topic is
> not really possible - we'd be slowing down all feeds, if I understand you
> correctly.
>
> Does that make sense?

I think that having a central TX buffer may turn itself into a global
bottleneck for the system.

Having said this, I think it would be a good idea to be more specific
about what you're trying to acheive with what mechanism (hopefully
breaking this down gives you an idea of how I'm interpreting your
questions, which I may be doing wrongly):

1. Centralized logging: You don't need a store and forward dongle to
log everything that passes through the system - you can just bind
every exchange in your system to one or more log queues;

2. Ingress Flow Control: Will be implemented by Channel.Flow command.

3. Egress Flow Control: IMHO this is where your problem is going to
be. To do proper credit based load balancing, you will need the
Basic.QoS command, which we have designed but not yet implemented. ATM
consumption is for all intents and purposes limited by the slowest
consumer. WRT adding resources dynamically, this is not specifically a
concern of the broker, since it has no control over consumers.
Thinking on my feet I have 2 suggestions:

- Always load every available hardware thread on the side of
consumption with the optimal amount of consumers and let the OS
scehduler load balance software threads for you - when there is no
work to do, they just spin in NOOPs
- If you think you can pull some extra CPU out of your hat at a
critical stage, then you could petition us to include a callback
handler mechanism for the Channel.Flow command. The current design
just blocks subsequent publication, but you could easily notify a
callback handler in the event loop which could take any course of
prophylactic action (automagically deploy more consumers if this made
sense or just sending a message to somebody's Blackberry for manual
intervention).

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.

HTH,

Ben