...
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 activate a networked durable subscription when a corresponding durable subscription reactivates, by default they are activated on startup. |
decreaseNetworkConsumerPriority |
false |
if true, starting at priority -5, decrease the priority for dispatching to a network Queue consumer the further away it is (in network hops) from the producer. When false all network consumers use same default priority(0) as local consumers |
networkTTL |
1 |
the number of brokers in the network that messages and subscriptions can pass through (sets both message&consumer -TTL) |
messageTTL |
1 |
(version 5.9) the number of brokers in the network that messages can pass through |
consumerTTL |
1 |
(version 5.9) the number of brokers in the network that subscriptions can pass through (keep to 1 in a mesh) |
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 |
useVirtualDestSubs |
false |
if true, the network connection will listen to advisory messages for virtual destination consumers |
staticallyIncludedDestinations |
empty |
destinations that match will always be passed across the network - even if no consumers have ever registered an interest |
duplex |
false |
if true, a network connection will be used to both produce AND Consume messages. This is useful for hub and spoke scenarios when the hub is behind a firewall etc. |
prefetchSize |
1000 |
Sets the prefetch size on the network connector's consumer. It must be > 0 because network consumers do not poll for messages |
suppressDuplicateQueueSubscriptions |
false |
(from 5.3) if true, duplicate subscriptions in the network that arise from network intermediaries will be suppressed. For example, given brokers A,B and C, networked via multicast discovery. A consumer on A will give rise to a networked consumer on B and C. In addition, C will network to B (based on the network consumer from A) and B will network to C. When true, the network bridges between C and B (being duplicates of their existing network subscriptions to A) will be suppressed. Reducing the routing choices in this way provides determinism when producers or consumers migrate across the network as the potential for dead routes (stuck messages) are eliminated. networkTTL needs to match or exceed the broker count to require this intervention. |
bridgeTempDestinations |
true |
Whether to broadcast advisory messages for created temp destinations in the network of brokers or not. Temp destinations are typically created for request-reply messages. Broadcasting the information about temp destinations is turned on by default so that consumers of a request-reply message can be connected to another broker in the network and still send back the reply on the temporary destination specified in the JMSReplyTo header. In an application scenario where most/all messages use request-reply pattern, this will generate additional traffic on the broker network as every message typically sets a unique JMSReplyTo address (which causes a new temp destination to be created and broadcasted via an advisory message in the network of brokers). When disabling this feature such network traffic can be reduced but then producer and consumers of a request-reply message need to be connected to the same broker. Remote consumers (i.e. connected via another broker in your network) won't be able to send the reply message but instead raise a "temp destination does not exist" exception. |
alwaysSyncSend |
false |
(version 5.6) When true, non persistent messages are sent to the remote broker using request/reply in place of a oneway. This setting treats both persistent and non-persistent messages the same. |
staticBridge |
false |
(version 5.6) If set to true, broker will not dynamically respond to new consumers. It will only use staticallyIncludedDestinations to create demand subscriptions |
... If configured like this, broker will try to listen for new consumers on ActiveMQ.Advisory.Consumer.NO_DESTINATION , which will never have messages so it will be protected from information on remote broker consumers. Dynamic networks and Virtual Destinations (New for 5.13.0) As described above, a network of brokers can be configured to only send messages to a remote broker when there's a consumer on an included destination. However, let's consider some cases of how dynamic flow occurs when Virtual Destinations are in use. Virtual Destination consumers and Composite Destinations Here is an example of two brokers networked together. The local broker contains the network connector configured with a dynamicallyIncludedDestination and the remote broker is configured with a CompositeTopic:
Code Block |
|
<networkConnector uri="static:(tcp://host)">
<dynamicallyIncludedDestinations>
<topic physicalName="include.test.bar"/>
</dynamicallyIncludedDestinations>
</networkConnector>
|
Code Block |
|
<compositeTopic name="include.test.bar" forwardOnly="false">
<forwardTo>
<queue physicalName="include.test.bar.forward" />
</forwardTo>
</compositeTopic >
|
In this example, let's consider a single consumer on the remote broker on the queue include.test.bar.forward. If a message is sent directly to the remote broker on the topic include.test.bar, it will be forwarded to the queue include.test.bar.forward and the consumer will receive it. However, if a message is published to the same topic on the local broker, this message will not be forwarded to the remote broker. The message is not forwarded because a consumer on the queue include.test.bar.forward would not be detected as part of the dynamicallyIncludedDestinations list so messages would not be forwarded to the remote broker unless there was a consumer on the original topic as well, in this case include.test.bar. This can be fixed by configuring the broker to listen for Virtual Destination Subscriptions. First, we need to configure the broker to send advisory messages when consumers come online onto a destination that matches a Virtual Destination. In this case, a match is determined by the use of a Destination Filter will determines if a a destination forwards to another destination. The configuration on the remote broker should be updated to set the property useVirtualDestSubs to true to enable this.
Code Block |
|
<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://activemq.org/config/1.0">
<broker name="broker1" useVirtualDestSubs="true">
.....
</broker>
</beans>
|
Second, we need to configure the network connector to listen for the new advisory messages:
Code Block |
|
<networkConnector uri="static:(tcp://host)" useVirtualDestSubs="true">
<dynamicallyIncludedDestinations>
<topic physicalName="include.test.bar"/>
</dynamicallyIncludedDestinations>
</networkConnector>
|
Now, if a consumer comes online for the queue include.test.bar.forward on the remote broker, the local broker will know to forward messages that are sent to the topic include.test.bar Virtual Destination consumers on destination Creation Now let's consider the use case above where there is the same composite topic but no consumers on the queue.
Code Block |
|
<compositeTopic name="include.test.bar" forwardOnly="false">
<forwardTo>
<queue physicalName="include.test.bar.forward" />
</forwardTo>
</compositeTopic >
|
There is a composite Topic configured on the remote broker and the local broker is networked to it. Even though we've enabled useVirtualDestSubs, messages wouldn't be forwarded to the remote broker unless a consumer comes online to the forwarded queue. This would cause messages to be dropped since they are sent to a topic. Sometimes it is desirable to have these messages forwarded based on the existence of the virtual destination. This only applies in the Queue case. For topics, messages should only be forwarded if there is a consumer or durable subscription.
Code Block |
|
<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://activemq.org/config/1.0">
<broker name="broker1" useVirtualDestSubs="true" useVirtualDestSubsOnCreation="true">
.....
</broker>
</beans>
|
With this configuration, when the Queue include.test.bar.forward is created, a Virtual Destination consumer advisory will be sent to the local broker so that it knows to forward messages based on the existence of the CompositeTopic and Queue existing. Virtual Destination consumers and Virtual Topics The above examples show how to configure a Composite destination but a Virtual Topic will also work. In the example below, a consumer on a Queue for a Virtual Topic will now cause demand and messages will be sent across a network.
Code Block |
|
<networkConnector uri="static:(tcp://host)">
<dynamicallyIncludedDestinations>
<topic physicalName="VirtualTopic.>"/>
</dynamicallyIncludedDestinations>
</networkConnector>
|
Code Block |
|
<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://activemq.org/config/1.0">
<broker name="broker1" useVirtualDestSubs="true" >
.....
</broker>
</beans>
|
Example Configuration using NetworkConnector properties ... |