Este conteúdo não está disponível no idioma selecionado.
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
-
An example is provided that 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. See the
core-bridge
example that is located in the<install_dir>/examples/features/standard/
directory of your broker installation. - 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”
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>
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.
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.
For more information about possible router configurations, see Using the AMQ Interconnect router.
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:
address { prefix: queue waypoint: yes }
For more information on this option, see Using the AMQ Interconnect router.
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.