Chapter 3. Dynamic and Static Propagation

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).

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).

The dynamic message propagation in this example proceeds as follows:

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>

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).

The static message propagation in this example proceeds as follows:

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.

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:

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.

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.

The static message propagation in this example proceeds as follows:

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>

By default, BrokerId is generated automatically, based on the host name of the machine and is used in broker to broker communication to identify peers. BrokerName is human readable and used on the disk to partition a store default directory and as the vm connection url. When BrokerName is transformed into a URL or into a file name, some of the characters are replaced. This means that the broker applies the transformation as needed. Hence it is recommended to limit the brokerName to characters that are valid in a URL.

If the brokerId is not specified in configuration, on a restart of a broker in a network, the restarted broker has a new unique brokerId and replay back to that broker is allowed after a restart. If the brokerId is specified, then after a restart the identity is preserved and replay back to that broker is suppressed.

It is valid to have a restarted broker look unique and it is valid to have its identity persist between restarts. For example, by default replay of a message back to where it came from (based on the brokerId) is not allowed. When used with a custom network bridge filter that limits replay of messages, specifying the brokerId is necessary to allow replay suppression to continue after the restart of a broker in the network.

Networked brokers use the brokerName (the human readable version) in network bridge naming and use the brokerId to prevent cycles and loops in a network topology.