This Confluence has been LDAP enabled, if you are an ASF Committer, please use your LDAP Credentials to login. Any problems file an INFRA jira ticket please.

Child pages
  • Networks of Brokers
Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 18 Next »

To provide massive scalability of a large messaging fabric you typically want to allow many brokers to be connected together into a network so that you can have as many clients as you wish all logically connected together - and running as many message brokers as you need based on your number of clients and network topology.

If you are using client/server or hub/spoke style topology then the broker you connect to becomes a single point of failure which is another reason for wanting a network (or cluster) of brokers so that you can survive failure of any particular broker, machine or subnet.

From 1.1 onwards of ActiveMQ supports networks of brokers which allows us to support distributed queues and topics across a network of brokers.

This allows a client to connect to any broker in the network - and fail over to another broker if there is a failure - providing from the clients perspective a HA cluster of brokers.

Configuring a network of brokers

For details on how to configure 3.x brokers see the ActiveMQ 3 Networks of Brokers

The easiest way to configure a network of brokers is via the Xml Configuration. There are two main ways to create a network of brokers

  • use a hard coded list of URIs (the networkConnector / networkChannel elements in the activemq.xsd.html ).
  • use Discovery to detect brokers (multicast or rendevous).

Example with a fixed list of URIs

Here is an example of using the fixed list of URIs

<?xml version="1.0" encoding="UTF-8"?>

<beans xmlns="http://activemq.org/config/1.0">

  <broker brokerName="receiver" persistent="false" useJmx="false">
    <transportConnectors>
      <transportConnector uri="tcp://localhost:62002"/>
    </transportConnectors>

    <networkConnectors>
      <networkConnector uri="static:(tcp://localhost:62001)" failover="true"/>
    </networkConnectors>

    <persistenceAdapter>
      <memoryPersistenceAdapter/>
    </persistenceAdapter>
  </broker>

</beans>

Example using multicast discovery

This example uses multicast discovery

<?xml version="1.0" encoding="UTF-8"?>

<beans xmlns="http://activemq.org/config/1.0">

  <broker name="sender" persistent="false" useJmx="false">
    <transportConnectors>
      <transportConnector uri="tcp://localhost:0" discoveryUri="multicast://default"/>
    </transportConnectors>

    <networkConnectors>
      <networkConnector uri="multicast://default"/>
    </networkConnectors>

    <persistenceAdapter>
      <memoryPersistenceAdapter/>
    </persistenceAdapter>
  </broker>

</beans>

Connecting to a network of brokers

if you are not using discovery, you can just use a hard coded list of URLs and you will connect randomly to one of the available brokers.

uri="static:(tcp://localhost:61616,tcp://remotehost:61616,tcp://..)" failover="true"

Make sure you set the failover="true" if your using static so that the a reconnect is done on broker to broker connection failure, so the JMS client will silently reconnect if one of your brokers goes down or becomes unreachable on the network.

You can set failover="false" option to avoid the auto-reconnect if you'd rather fail and disable that connection if your broker goes down.

If it is disabled, then the broker would only connect once and thier network connection fails, it will never be re-established.
Failover is usually not needed if a multicast discovery is used since the broker connections will be restablished when the failed brokers come back online.

NetworkConnector Properties

property

default

description

name

bridge

name of the network - for more than one network connector between the same two brokers - use different names

dynamicOnly

false

if true, only forward messages if a consumer is active on the connected broker

decreaseNetworkConsumerPriority

false

decrease the priority for dispatching to a Queue consumer the further away it is (in network hops) from the producer

networkTTL

1

the number of brokers in the network that messages and subscriptions can pass through

conduitSubscriptions

true

multiple consumers subscribing to the same destination are treated as one consumer by the network

excludedDestinations

empty

destinations matching this list won't be forwarded across the network

dynamicallyIncludedDestinations

empty

destinations that match this list will be forwarded across the network n.b. an empty list means all destinations not in the exluded list will be forwarded

staticallyIncludedDestinations

empty

destinations that match will always be passed across the network - even if no consumers have ever registered an interest

failover

false

If failover should be used so that network we reconnect even when the broker fails

Example Configuration using NetworkConnector properties

This part of an example configuration for a Broker

<networkConnectors>
      <networkConnector uri="static://(tcp://localhost:61617)" failover="true"
         name = bridge
         dynamicOnly = false
         conduitSubscriptions = true
         decreaseNetworkConsumerPriority = false>
      	<excludedDestinations>
      		<queue physicalName="exclude.test.foo"/>
      		<topic physicalName="exclude.test.bar"/>
      	</excludedDestinations>
      	<dynamicallyIncludedDestinations>
      		<queue physicalName="include.test.foo"/>
      		<topic physicalName="include.test.bar"/>
      	</dynamicallyIncludedDestinations>
      </networkConnector>
    </networkConnectors>

It is possible to have more than one network connector between two brokers. Each network connector uses one underlying transport connection, so you may wish to do this to increase throughput, or have a more flexible configuration.
For example, if using distributed queues, you may wish to have equivlanent weighting to queue receivers across the network, but only when the receivers are active - e.g.

<networkConnectors>
      <networkConnector uri="static://(tcp://localhost:61617)" failover="true"
         name = queues_only
         dynamicOnly = true
         conduitSubscriptions = false
         decreaseNetworkConsumerPriority = false>
      	<excludedDestinations>
      		<topic physicalName=">"/>
      	</excludedDestinations>
      </networkConnector>
    </networkConnectors>

N.B. You can use wildcards in inclusive , exclusive destination properties
N.B. Do not change the name of the bridge or the name of the Broker if you are using durable topic subscribers across the network. Internally ActiceMQ uses the network name and broker name to build a unique but repeatable durable subscriber name for the network.

Trying out using a network of brokers

If you run the following commands in separate shells you'll have 2 brokers auto-discoverying themselves and 2 clients using fixed-URLs

maven -o server -Dconfig=xbean:file:src/test/resources/org/apache/activemq/usecases/receiver.xml
maven -o server -Dconfig=xbean:file:src/test/resources/org/apache/activemq/usecases/sender.xml
maven -o consumer -Durl=tcp://localhost:62002
maven -o producer -Durl=tcp://localhost:62001

Or to try the same thing again using Zeroconf discovery you could try this

maven -o server -Dconfig=src/test/org/activemq/usecases/receiver-zeroconf.xml
maven -o server -Dconfig=src/test/org/activemq/usecases/sender-zeroconf.xml
maven -o consumer -Durl=tcp://localhost:62002
maven -o producer -Durl=tcp://localhost:62001
  • No labels