Chapter 3. Dynamic and Static Propagation
Abstract
Because of the special nature of routing in a messaging system, the propagation of messages must be inherently dynamic. That is, the broker network must keep track of the active consumers attached to the network and the routing of messages is governed by the real-time transmission of advisory messages (subscriptions). However, there are cases in which messages need to be propagated in the absence of subscriptions.
Overview
The fundamental purpose of a broker network is to route messages to their intended recipients, which are consumers that could be attached at any point in the network. The peculiar difficulty in devising routing rules for a messaging network is that messages are sent to an abstract destination rather than a physical destination. In other words, a message might be sent to a specific queue, but that gives you no clue as to which broker or which consumer that message should ultimately be sent to. Contrast this with the Internet Protocol (IP), where each message packet includes a header with an IP address that references the physical location of the destination host.
Because of the special nature of routing in a messaging system, the propagation of messages must be inherently dynamic. That is, the broker network must keep track of the active consumers attached to the network and the routing of messages is governed by the real-time transmission of advisory messages (subscriptions).
Dynamic propagation
Figure 3.1, “Dynamic Propagation of Queue Messages” illustrates how dynamic propagation works for messages sent to a queue. The broker connectors in this network are simple (non-duplex).
Figure 3.1. Dynamic Propagation of Queue Messages
The dynamic message propagation in this example proceeds as follows:
- As shown in part (a), initially, there are no consumers attached to the network. A producer,
P
, connects to broker A and starts sending messages to a particular queue,TEST.FOO
. Because there are no consumers attached to the network, all of the messages accumulate in broker A. The messages do not propagate any further at this time. - As shown in part (b), a consumer, C, now connects to the network at broker E and subscribes to the same queue,
TEST.FOO
, to which the producer is sending messages. - The consumer's subscription,
s
, propagates through the broker network, following the reverse arrow direction, until it reaches broker A. - After broker A receives the subscription,
s
, it knows that it can send the messages accumulated in the queue,TEST.FOO
, to the consumer, C. Based on the information in the subscription,s
, broker A sends messages along the path ABCE to reach consumer C.
Static propagation
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:
<networkConnectors> <networkConnector name="linkToBrokerB" uri="static:(tcp://localhost:61002)" networkTTL="3"> <staticallyIncludedDestinations> <queue physicalName="TEST.FOO"/> </staticallyIncludedDestinations> </networkConnector> </networkConnectors>
Note
You can use wildcards when specifying statically included queue names or topic names—for example, the
physicalName
attribute in the preceding example could be set to TEST.*
. See Chapter 4, Destination Filtering.
Consider the network shown in Figure 3.2, “Static Propagation of Queue Messages”. 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)
.
Figure 3.2. Static Propagation of Queue Messages
The static message propagation in this example proceeds as follows:
- 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
. - 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. - 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. - 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
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.
Duplex mode and static propagation
It is also possible to use static propagation in combination with duplex connectors. In this case, messages can propagate statically in either direction through the duplex connector. For example, Figure 3.3, “Duplex Mode and Static Propagation” shows a network of four brokers, B, C, D, and E, linked by duplex connectors. All of the connectors have enabled static propagation for the queue,
TEST.FOO
.
Figure 3.3. Duplex Mode and Static Propagation
In part (a), the producer, P, connects to broker B and sends 10 messages to the queue,
TEST.FOO
. The static message propagation then proceeds as follows:
- Because the duplex connector,
{B,C}
, has enabled static propagation for the queue,TEST.FOO
, the 10 messages on broker B are forwarded to broker C. - Because the duplex 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. At the end of the static propagation, there are 5 messages on broker D and 5 messages on broker E.
In part (b), the producer, P, connects to broker C and sends 9 messages to the queue,
TEST.FOO
. Because static propagation is enabled on all of the connectors, broker C sends messages alternately to B, D, and E. At the end of the static propagation, there are 3 messages on broker B, 3 messages on broker D, and 3 messages on broker E.
Self-avoiding paths
Brokers implement a strategy of self-avoiding paths in order to prevent pathalogical routes from occurring in a statically configured broker network. For example, consider what could happen, if a closed loop occurs in a network with statically configured duplex connectors. If the brokers followed a strategy of simply forwarding messages to a neighbouring broker (or brokers), messages could end up circulating around the closed loop for ever. This does not happen, however, because the broker network applies a strategy of self-avoiding paths to static propagation. For example, Figure 3.4, “Self-Avoiding Paths” shows a network consisting of three brokers, A, B, and C, linked by statically configured duplex connectors. The path ABCA forms a closed loop in this network.
Figure 3.4. Self-Avoiding Paths
The static message propagation in this example proceeds as follows:
- The producer, P, connects to broker A and sends 100 messages to the queue,
TEST.FOO
. - The 100 messages on broker A are alternately sent to broker B and broker C. The 50 messages sent to broker B are immediately forwarded to broker C, but at this point the messages stop moving and remain on broker C. The self-avoiding path strategy dictates that messages can not return to a broker they have already visited.
- Similarly, the 50 messages sent from broker A to broker C are immediately forwarded to broker B, but do not travel any further than that.
brokerId and self-avoiding paths
Red Hat JBoss A-MQ uses broker ID values (set by the
broker
element's brokerId
attribute) to figure out self-avoiding paths. By default, the broker ID value is generated dynamically and assigned a new value each time a broker starts up. If your network topology relies on self-avoiding paths, however, this default behavior is not appropriate. If a broker is stopped and restarted, it would rejoin the network with a different broker ID, which confuses the self-avoiding path algorithm and can lead to stuck messages.
In the context of a broker network, therefore, it is recommended that you set the broker ID explicitly on the
broker
element, as shown in the following example:
<broker xmlns="http://activemq.apache.org/schema/core"
brokerName="brokerA" brokerId="A"... >
...
</broker>
Note
Make sure you always specify a broker ID that is unique within the current broker network.