Ce contenu n'est pas disponible dans la langue sélectionnée.

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:

address {
    prefix: queue
    waypoint: yes
}
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

Apprendre

Essayez, achetez et vendez

Communautés

À propos de la documentation Red Hat

Nous aidons les utilisateurs de Red Hat à innover et à atteindre leurs objectifs grâce à nos produits et services avec un contenu auquel ils peuvent faire confiance.

Rendre l’open source plus inclusif

Red Hat s'engage à remplacer le langage problématique dans notre code, notre documentation et nos propriétés Web. Pour plus de détails, consultez leBlog Red Hat.

À propos de Red Hat

Nous proposons des solutions renforcées qui facilitent le travail des entreprises sur plusieurs plates-formes et environnements, du centre de données central à la périphérie du réseau.

© 2024 Red Hat, Inc.