LibraryPrintFeedback

Using Networks of Brokers

Version 7.1

December 2012
Trademark Disclaimer
Third Party Acknowledgements

Updated: 08 Jan 2014

Table of Contents

1. Introduction
2. Network Connectors
3. Dynamic and Static Propagation
4. Destination Filtering
5. Using JMS Message Selectors
6. Network Topologies
7. Optimizing Routes
Choosing the Shortest Route
Suppressing Duplicate Routes
8. Discovering Brokers
Discovery Agents
Fuse Fabric Discovery Agent
Static Discovery Agent
Multicast Discovery Agent
Zeroconf Discovery Agent
Dynamic Discovery Protocol
Fanout Protocol
9. Load Balancing
Balancing Consumer Load
Managing Producer Load
Index

List of Figures

2.1. Single Connector
2.2. Connectors in Each Direction
2.3. Duplex Connector
2.4. Multiple Connectors
2.5. Conduit Subscriptions
3.1. Dynamic Propagation of Queue Messages
3.2. Static Propagation of Queue Messages
3.3. Duplex Mode and Static Propagation
3.4. Self-Avoiding Paths
5.1. JMS Message Selectors and Conduit Subscriptions
6.1. Concentrator Topology
6.2. Hub and Spoke Topology
6.3. Tree Topology
6.4. Mesh Topology
6.5. The Complete Graph, K5
7.1. Shortest Route in a Mesh Network
7.2. Duplicate Subscriptions in a Network
9.1. Message Flow when Conduit Subscriptions Enabled
9.2. Message Flow when Conduit Subscriptions Disabled
9.3. Load Balancing with the Concentrator Topology

List of Tables

4.1. Destination Name Wildcards
4.2. Example Destination Wildcards
8.1. Dynamic Discovery Protocol Options
8.2. Fanout Protocol Options

List of Examples

2.1. Single connector configuration
2.2. Two way connector
2.3. Duplex connector configuration
4.1. Network Connector Using Inclusive Filtering
4.2. Network Connector Using Exclusive Filtering
4.3. Combining Exclusive and Inclusive Filters
5.1. Disabling Conduit Subscriptions
7.1. Network Connector for Choosing the Shortest Route
7.2. Network Connector that Suppresses Duplicate Routes
7.3. Setting a Broker's ID
8.1. Enabling a Discovery Agent on a Broker
8.2. Fuse Fabric Discovery Agent URI Format
8.3. Client Connection URL using Fuse Fabric Discovery
8.4. Static Discovery Agent URI Format
8.5. Discovery URI using the Static Discovery Agent
8.6. Multicast Discovery Agent URI Format
8.7. Enabling a Multicast Discovery Agent on a Broker
8.8. Client Connection URL using Multicast Discovery
8.9. Zeroconf Discovery Agent URI Format
8.10. Enabling a Multicast Discovery Agent on a Broker
8.11. Client Connection URL using Zeroconf Discovery
8.12. Dynamic Discovery URI
8.13. Discovery Protocol URI
8.14. Injecting Transport Options into a Discovered Transport
8.15. Fanout URI Syntax
8.16. Fanout Protocol URI
9.1. Disabling Conduit Subscriptions
9.2. Separate Configuration of Topics and Queues

Figure 2.1 shows a single network connector from broker A to broker B. The arrow on the connector indicates the direction of message propagation (from A to B). Subscriptions propagate in the opposite direction (from B to A). Because of the restriction on the direction of message flow in this network, it is advisable to connect producers only to broker A and consumers only to broker B. Otherwise, some messages might not be able to reach the intended consumers.


When the connector arrow points from A to B, this implies that the network connector is actually defined on broker A. For example, the following fragment from broker A's configuration file shows the network connector that connects to broker B:


The networkConnector element in the preceding example sets the following basic attributes:

By default, after passing through a network connector, subscriptions to the same queue or subscriptions to the same topic are automatically consolidated into a single subscription known as a conduit subscription. Figure 2.5 shows an overview of how the topic subscriptions from two consumers, C1 and C2, are consolidated into a single conduit subscription after propagating from broker B to broker A.


In this example, each consumer subscribes to the identical topic, t, which gives rise to the subscriptions, C1:t and C2:t in broker B. Both of these subscriptions propagate automatically from broker B to broker A. Because broker A has conduit subscriptions enabled, its network connector consolidates the duplicate subscriptions, C1:t and C2:t, into a single subscription, B:t. Now, if a message on topic t is sent to broker A, broker A sends a single copy of the message to broker B, to honor the conduit subscription, B:t. Broker B then sends a copy of the message to each consumer, to honor the topic subscriptions, C1:t and C2:t.

It is essential to enable conduit subscription in order to avoid duplication of topic messages. Consider what would happen in Figure 2.5 if conduit subscription was disabled. In this scenario, two subscriptions, B:C1:t and B:C2:t, would be registered in broker A. Now, if a message on topic t is sent to broker A, broker A would send two copies of the message to broker B, to honor the topic subscriptions, B:C1:t and B:C2:t. Broker B would then send two copies of the message to each consumer, to honor the topic subscriptions, C1:t and C2:t. In other words, each consumer would receive the topic message twice.

Conduit subscriptions can optionally be disabled by setting the conduitSubscriptions attribute to false on the networkConnector element. See Balancing Consumer Load for more details.

Static propagation refers to message propagation that occurs in the absence of subscription information. Sometimes, because of the way a broker network is set up, it can make sense to move messages between brokers, even when there is no relevant subscription information.

Static propagation is configured by specifying the queue (or queues) that you want to statically propagate. Into the relevant networkConnector element, insert staticallyIncludedDestinations as a child element and then list the queues and topics you want to propagate using the queue and topic child elements. For example, to specify that messages in the queue, TEST.FOO, are statically propagated from A to B, you would define the network connector in broker A's configuration as follows:

[Note]Note

You cannot use wildcards when specifying statically included queue names or topic names.

Consider the network shown in Figure 3.2. This network is set up so that consumers only attach to broker D or to broker E Messages sent to the queue, TEST.FOO, are configured to propagate statically on all on all of the network connectors, (A,B), (B,C), (C,D), and (C,E).


The static message propagation in this example proceeds as follows:

  1. Initially, there are no consumers attached to the network. A producer, P, connects to broker A and sends 10 messages to the queue, TEST.FOO.

  2. Because the network connector, (A,B), has enabled static propagation for the queue, TEST.FOO, the 10 messages on broker A are forwarded to broker B.

  3. Likewise, because the network connector, (B,C), has enabled static propagation for the queue, TEST.FOO, the 10 messages on broker B are forwarded to broker C.

  4. Finally, because the network connectors, (C,D) and (C,E), have enabled static propagation for the queue, TEST.FOO, the 10 messages on broker C are alternately sent to broker D and broker E. In other words, the brokers, D and E, receive every second message. Hence, at the end of the static propagation, there are 5 messages on broker D and 5 messages on broker E.

[Note]Note

Using the preceding static configuration, it is possible for messages to get stuck in a particular broker. For example, if a consumer now connects to broker E, it will receive the 5 messages stored on broker E, but it will not receive the 5 messages stored on broker D. The messages remain stuck on broker D until a consumer connects directly to it.

Trouble arises when message selectors are combined with conduit subscriptions for consumers that are listening on the same queue.

Consider the broker network shown in Figure 5.1. Consumers C1 and C2 subscribe to the same queue and they also define JMS message selectors. C1 selects messages for which the region header is equal to us. C2 selects messages for which the region header is equal to emea.


The consumer subscriptions, s1 and s2, automatically propagate to broker A. Because these subscriptions are both on the same queue broker A combines the subscriptions into a single conduit subscription, cs, which does not include any selector details. When the producer P starts sending messages to the queue, broker A forwards the messages alternately to broker B and broker C without checking whether the messages satisfy the relevant selectors.

The best case scenario is that, by luck, the messages are forwarded to the broker with a selector that matches the message. The worst case scenario is that all of the messages for region emea end up on broker B and all of the messages for region us end up on broker C. Chances are that the result would be somewhere in the middle. However, that means that at least some messages will sit at a broker where they will never be consumed.

If the consumers were both listening to a topic instead of a queue broker A would send a copy of every message to both networked brokers. All of the messages would get processed because C1 would consume the messages for the US region and C2 would consumer the messages for the EMEA region. However, any messages for the EMEA region would sit unconsumed in broker C and any messages for the US region would sit unconsumed in broker B.

In network topologies such as a hub-and-spoke or a tree there exists a unique route between any two brokers. For topologies, such as a mesh or a complete graph, it is possible to have multiple routes between any two brokers. In such cases, you may need simplify the routing behavior, so that an optimum route is preferred by the network.

Fuse MQ Enterprise provides two configuration settings that work in conjunction to refine routing behavior:

  • decreaseNetworkConsumerPriority—deprecates the priority of a network connector based on the number of hops from the message's origin so that messages are routed along the shortest route

  • suppressDuplicateQueueSubscriptions—suppresses duplicate subscriptions from intermediary brokers so that alternative paths are reduced

[Tip]Tip

To be most effective these properties should be set on all of the network connectors in the network of brokers.

In order for location transparency to work, the members of a messaging application need a way for discovering each other. In Fuse MQ Enterprise this is accomplished using two pieces:

  • discovery agents—components that advertise the brokers available to other members of a messaging applicaiton

  • discovery URI—a URI that looks up all of the discoverable brokers and presents them as a list of actual URIs for use by the client or network connector

A discovery agent is a mechanism that advertises available brokers to clients and other brokers. When a client, or broker, using a discovery URI starts up it will look for any brokers that are available using the specified discovery agent. The clients will update their lists periodically using the same mechanism.

How a discovery agent learns about the available brokers varies between agents. Some agents use a static list, some use a third party registry, and some rely on the brokers to provide the information. For discovery agents that rely on the brokers for information, it is necessary to enable the discovery agent in the message broker configuration. For example, to enable the multicast discovery agent on an Openwire endpoint, you edit the relevant transportConnector element as shown in Example 8.1.


Where the discoveryUri attribute on the transportConnector element is initialized to multicast://default.

[Tip]Tip

If a broker uses multiple transport connectors, you need to configure each transport connector to use a discovery agent individually. This means that different connectors can use different discovery mechanisms or that one or more of the connectors can be indiscoverable.

Fuse MQ Enterprise currently supports the following discovery agents:

The zeroconf discovery agent is derived from Apple’s Bonjour Networking technology, which defines the zeroconf protocol as a mechanism for discovering services on a network. Fuse MQ Enterprise bases its implementation of the zeroconf discovery agent on JmDSN, which is a service discovery protocol that is layered over IP/multicast and is compatible with Apple Bonjour.

The agent requires that each broker you want to advertise is configured to use a multicast discovery agent to publish its details to a multicast group. Clients using the zeroconf agent as part of the discovery URI they use for connecting to a broker will use the agent to receive the list of available brokers advertising in the specified multicast group.

[Important]Important

Your local network (LAN) must be configured to use IP/multicast for the zeroconf agent to work.

Example 8.12 shows the syntax for a discovery URI.


DiscoveryAgentUri is URI for the discovery agent used to build up the list of available brokers. Discovery agents are described in Discovery Agents.

The options, ?Options, are specified in the form of a query list. The discovery options are described in Table 8.1. You can also inject transport options as described in Setting options on the discovered transports.

[Tip]Tip

If no options are required, you can drop the parentheses from the URI. The resulting URI would take the form discovery://DiscoveryAgentUri

Example 8.15 shows the syntax for a fanout URI.


DiscoveryAgentUri is URI for the discovery agent used to build up the list of available brokers. Discovery agents are described in Discovery Agents.

The options, ?Options, are specified in the form of a query list. The discovery options are described in Table 8.2. You can also inject transport options as described in Setting options on the discovered transports.

[Tip]Tip

If no options are required, you can drop the parentheses from the URI. The resulting URI would take the form fanout://DiscoveryAgentUri

C

concentrator topology, Concentrator topology
conduit subscription
disabling, Resolving the problem, Disabling conduit subscriptions
impact on queues, Default load behavior
conduitSubscriptions, Resolving the problem, Disabling conduit subscriptions

D

decreaseNetworkConsumerPriority, Connector configuration
destination filtering, Separate connectors for topics and queues
by exclusion, Filtering destinations by exclusion
by inclusion, Filtering destinations by inclusion
destinations
wildcards, Destination wildcards
discovery agent
Fuse Fabric, Fuse Fabric Discovery Agent
multicast, Multicast Discovery Agent
static, Static Discovery Agent
zeroconf, Zeroconf Discovery Agent
discovery protocol
backOffMultiplier, Transport options
initialReconnectDelay, Transport options
maxReconnectAttempts, Transport options
maxReconnectDelay, Transport options
URI, URI syntax
useExponentialBackOff, Transport options
discovery URI, URI syntax
discovery://, URI syntax
discoveryUri, Configuring a broker, Configuring a broker
dynamicallyIncludedDestinations, Filtering destinations by inclusion
queue, Filtering destinations by inclusion
topic, Filtering destinations by inclusion

F

fabric://, URI
fanout protocol
backOffMultiplier, Transport options
fanOutQueues, Transport options
initialReconnectDelay, Transport options
maxReconnectAttempts, Transport options
maxReconnectDelay, Transport options
minAckCount, Transport options
URI, URI syntax
useExponentialBackOff, Transport options
fanout URI, URI syntax
fanout://, URI syntax
Fuse Fabric discovery agent
URI, URI

M

multicast discovery agent
broker configuration, Configuring a broker
URI, URI
multicast://, URI

N

network connectors
multiple, Separate connectors for topics and queues
networkConnector, Separate connectors for topics and queues
conduitSubscriptions, Resolving the problem, Disabling conduit subscriptions
decreaseNetworkConsumerPriority, Connector configuration
dynamicallyIncludedDestinations, Filtering destinations by inclusion
excludedDestinations, Filtering destinations by exclusion
name, Single connector
networkTTL, Single connector
suppressDuplicateQueueSubscriptions, Connector configuration
uri, Single connector

S

shortest route, Overview
static discovery agent
URI, Using the agent
static://, Using the agent
suppressDuplicateQueueSubscriptions, Connector configuration

T

transportConnector
discoveryUri, Configuring a broker, Configuring a broker

W

wildcards
destinations, Destination wildcards

Z

zeroconf discovery agent
broker configuration, Configuring a broker
URI, URI
zeroconf://, URI