ActiveMQ Broker Networks - Think, Demand Forwarding Bridge

When we build a mental model of how something works, our initial images are always tainted by our experience of the words used to describe it. Sometimes we have to remold our existing perception of the words based on our new learning context, when the words have multiple meanings, we can often start from the wrong premise.

With this in mind, I want to share the meaning of the words I have used to describe ActiveMQ Broker Networks and provide some context to the words. The hope is that this will help build a model in your mind that is a valid reflection of their reality.


A broker network is two or more brokers that are connected via a "Demand Forwarding Bridge". Lets expand on each word in turn, but in reverse:

Bridge

This part is easy, a bridge it is a link between two brokers. The bridge is identified by the transport url of the remote broker it will connect to. The bridge is realized by a socket connection over which messages will pass for specific destinations. A bridge is initiated on a broker via xml configuration of the form:
 <networkConnector url="scheme://host:port" />

Forwarding

The directionality is implicit in the forwarding. Messages flow in one direction only, from the local broker where the bridge is created, to the remote broker where messages end up. Messages are forwarded, which means they are consumed from the local broker, and sent to the remote broker. This is regular JMS send semantics, the message is acknowledged locally when the send to the remote broker completes. So a message only lives in one broker at a time.

Demand

The bridge is aware of demand. In ActiveMQ, demand for messages comes from consumers. A bridge will only forward messages if it knows that there are consumers for that destination on the remote broker. The trick here is the use of ActiveMQ Advisory messages. When a bridge is started, it registers a  consumer with the remote broker for consumer advisory messages. In this way, the bridge becomes aware of the creation and removal of consumers on the remote broker. The bridge reacts to a new consumer advisory notification by creating a local (proxy) consumer for that destination. When this proxy consumer gets a message dispatch, it responds by forwarding (sending) the message to the remote broker. When the remote consumer disconnects, the corresponding remove advisory notification fires and the local proxy consumer is removed. Messages are no longer forwarded for that destination. In this way, the bridge is led by demand.

Next time you encounter <networkConnector ... /> in xml configuration, think of these three words, Demand, Forwarding, Bridge", then proceed to (re)build your mental model.