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”
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.

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.

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.

Red Hat logoGithubRedditYoutubeTwitter

Learn

Try, buy, & sell

Communities

About Red Hat Documentation

We help Red Hat users innovate and achieve their goals with our products and services with content they can trust.

Making open source more inclusive

Red Hat is committed to replacing problematic language in our code, documentation, and web properties. For more details, see the Red Hat Blog.

About Red Hat

We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.

© 2024 Red Hat, Inc.