Chapter 17. Bridging brokers Bridges provide a method to connect two brokers, forwarding messages from one to the other. The following bridges are available: Core The core-bridge example demonstrates a core bridge deployed on one broker, which consumes messages from a local queue and forwards them to an address on a second broker. Mirror See Chapter 16, Configuring a multi-site, fault-tolerant messaging system using broker connections Sender and receiver See Section 17.1, "Sender and receiver configurations for broker connections" Peer See Section 17.2, "Peer configurations for broker connections" Note The broker.xml element for Core bridges is bridge . The other bridging techniques use the <broker-connection> element. 17.1. Sender and receiver configurations for broker connections It is possible to connect a broker to another broker by creating a sender or receiver broker connection element in the <broker-connections> section of broker.xml . For a sender , the broker creates a message consumer on a queue that sends messages to another broker. For a receiver , the broker creates a message producer on an address that receives messages from another broker. Both elements function as a message bridge. However, there is no additional overhead required to process messages. Senders and receivers behave just like any other consumer or producer in a broker. Specific queues can be configured by senders or receivers. Wildcard expressions can be used to match senders and receivers to specific addresses or sets of addresses. When configuring a sender or receiver, the following properties can be set: address-match : Match the sender or receiver to a specific address or set of addresses, using a wildcard expression. queue-name : Configure the sender or receiver for a specific queue. Using address expressions: <broker-connections> <amqp-connection uri="tcp://HOST:PORT" name="other-server"> <sender address-match="queues.#"/> <!-- notice the local queues for remotequeues.# need to be created on this broker --> <receiver address-match="remotequeues.#"/> </amqp-connection> </broker-connections> <addresses> <address name="remotequeues.A"> <anycast> <queue name="remoteQueueA"/> </anycast> </address> <address name="queues.B"> <anycast> <queue name="localQueueB"/> </anycast> </address> </addresses> Using queue names: <broker-connections> <amqp-connection uri="tcp://HOST:PORT" name="other-server"> <receiver queue-name="remoteQueueA"/> <sender queue-name="localQueueB"/> </amqp-connection> </broker-connections> <addresses> <address name="remotequeues.A"> <anycast> <queue name="remoteQueueA"/> </anycast> </address> <address name="queues.B"> <anycast> <queue name="localQueueB"/> </anycast> </address> </addresses> Note Receivers can only be matched to a local queue that already exists. Therefore, if receivers are being used, ensure that queues are pre-created locally. Otherwise, the broker cannot match the remote queues and addresses. Note Do not create a sender and a receiver with the same destination because this creates an infinite loop of sends and receives. 17.2. Peer configurations for broker connections The broker can be configured as a peer which connects to a AMQ Interconnect instance and instructs it that the broker will act as a store-and-forward queue for a given AMQP waypoint address configured on that router. In this scenario, clients connect to a router to send and receive messages using a waypoint address, and the router routes these messages to or from the queue on the broker. This peer configuration creates a sender and receiver pair for each destination matched in the broker connections configuration on the broker. These pairs include configurations that enable the router to collaborate with the broker. This feature avoids the requirement for the router to initiate a connection and create auto-links. With a peer configuration, the same properties are present as when there are senders and receivers. For example, a configuration where queues with names beginning queue . act as storage for the matching router waypoint address would be: <broker-connections> <amqp-connection uri="tcp://HOST:PORT" name="router"> <peer address-match="queues.#"/> </amqp-connection> </broker-connections> <addresses> <address name="queues.A"> <anycast> <queue name="queues.A"/> </anycast> </address> <address name="queues.B"> <anycast> <queue name="queues.B"/> </anycast> </address> </addresses> There must be a matching address waypoint configuration on the router. This instructs it to treat the particular router addresses the broker attaches to as waypoints. For example, see the following prefix-based router address configuration: Note Do not use the peer option to connect directly to another broker. If you use this option to connect to another broker, all messages become immediately ready to consume, creating an infinite echo of sends and receives.

Commands:
<broker-connections> <amqp-connection uri="tcp://HOST:PORT" name="other-server"> <sender address-match="queues.#"/> <!-- notice the local queues for remotequeues.# need to be created on this broker --> <receiver address-match="remotequeues.#"/> </amqp-connection> </broker-connections> <addresses> <address name="remotequeues.A"> <anycast> <queue name="remoteQueueA"/> </anycast> </address> <address name="queues.B"> <anycast> <queue name="localQueueB"/> </anycast> </address> </addresses>
<broker-connections> <amqp-connection uri="tcp://HOST:PORT" name="other-server"> <receiver queue-name="remoteQueueA"/> <sender queue-name="localQueueB"/> </amqp-connection> </broker-connections> <addresses> <address name="remotequeues.A"> <anycast> <queue name="remoteQueueA"/> </anycast> </address> <address name="queues.B"> <anycast> <queue name="localQueueB"/> </anycast> </address> </addresses>
<broker-connections> <amqp-connection uri="tcp://HOST:PORT" name="router"> <peer address-match="queues.#"/> </amqp-connection> </broker-connections> <addresses> <address name="queues.A"> <anycast> <queue name="queues.A"/> </anycast> </address> <address name="queues.B"> <anycast> <queue name="queues.B"/> </anycast> </address> </addresses>
address { prefix: queue waypoint: yes }