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 (this only applies to dynamicallyIncludedDestinations) |
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
excluded list will be forwarded. Starting with version 5.14.0 the flag forceDurable can be appended to a topic which will ensure the subscription between the two brokers is always a durable subscription. See
Jira |
server |
ASF JIRA |
columns |
key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution |
serverId |
5aa69414-a9e9-3523-82ec-879b028fb15b |
key |
AMQ-6383 |
|
|
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. Starting with version 5.14.0 the flag forceDurable can be appended to a topic which will ensure the subscription between the two brokers is always a durable subscription. See
Jira |
server |
ASF JIRA |
columns |
key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution |
serverId |
5aa69414-a9e9-3523-82ec-879b028fb15b |
key |
AMQ-6383 |
|
|
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 |
userName |
null |
The username to authenticate against the remote broker |
password |
null |
The password for the username to authenticate against the remote broker |
sslContext |
null |
The sslContext to use, overriding the brokerService or JVM ssl defaults (5.16.0) |