7.2. Suppressing Duplicate Routes
Abstract
Configuring your network to always prefer the shortest route does not ensure deterministic routing. The alternate routes are still available under heavy load conditions. This can result in dead routes if a consumer fails or migrates to a new broker. Red Hat JBoss A-MQ allows you to suppress the duplicate subscriptions that create alternate routes.
Overview
Configuring your broker network to prefer the shortest route does not ensure that routing is deterministic. Under heavy load, the brokers will use the alternate routes to optimize performance. The danger of this is that if the message is routed along the longer alternate route and the consumer dies, the route becomes a dead-end and the message becomes stuck.
Red Hat JBoss A-MQ allows you to configure your network connectors to suppress duplicate subscriptions that arise from intermediary brokers. This has the effect of eliminating alternate paths between the networked brokers because only direct connections are recognized.
Connector configuration
To suppress duplicate subscriptions you set the
networkConnector
element's suppressDuplicateQueueSubscriptions
attribute to true
on all of the network connectors in you network. Example 7.2, “Network Connector that Suppresses Duplicate Routes” shows a network connector that is configured to suppress duplicate routes.
Example 7.2. Network Connector that Suppresses Duplicate Routes
<networkConnectors> <networkConnector name="linkToBrokerB" uri="static:(tcp://localhost:61002)" suppressDuplicateQueueSubscriptions="true"/> </networkConnectors>
Broker ID and duplicate routes
JBoss A-MQ uses the brokers' IDs to figure out duplicate routes. In order for the suppression of duplicate routes to work reliably, you must give each broker a unique ID by explicitly setting the
broker
element's brokerId
for each broker in the network. Example 7.3, “Setting a Broker's ID” shows configuration setting a broker's ID.
Example 7.3. Setting a Broker's ID
<broker xmlns="http://activemq.apache.org/schema/core"
brokerName="brokerA" brokerId="A"... >
...
</broker>
Example
Consider the network of brokers, A, B, and C, shown in Figure 7.2, “Duplicate Subscriptions in a Network”. In this scenario, a producer, P, connects to broker A and a consumer, C1 that subscribes to messages from P connects to broker B. The network TTL is equal to
2
, so two alternative routes are possible:
- the short route:
PABC1
- long route:
PACBC1
Figure 7.2. Duplicate Subscriptions in a Network
If you set
decreaseNetworkConsumerPriority
to true
, the short route is preferred. and messages are propagated along the route PABC1
. However, under heavy load conditions, the short route, PABC1
, can become overloaded and in this case the broker, A, will fall back to the long route, PACBC1
. The problem with this scenario is that when the consumer, C1, shuts down, it can lead to messages getting stuck on broker C.
Setting
suppressDuplicateQueueSubscriptions
attribute to true
will suppress the intermediary subscriptions that are generated between A and B. Because this subscription is suppressed the only route left is PACC1
. Routing becomes fully deterministic.
Note
In the example shown in Figure 7.2, “Duplicate Subscriptions in a Network”, you could have suppressed the long route by reducing the network TTL to 1. Normally, however, in a large network you do not have the option of reducing the network TTL arbitrarily. The network TTL has to be large enough for messages to reach the most distant brokers in the network.