Author: buildbot
Date: Mon Jan 21 13:25:05 2019
New Revision: 1039296
Log:
Production update by buildbot for activemq
Modified:
websites/production/activemq/content/cache/main.pageCache
websites/production/activemq/content/networks-of-brokers.html
Modified: websites/production/activemq/content/cache/main.pageCache
==============================================================================
Binary files - no diff available.
Modified: websites/production/activemq/content/networks-of-brokers.html
==============================================================================
--- websites/production/activemq/content/networks-of-brokers.html (original)
+++ websites/production/activemq/content/networks-of-brokers.html Mon Jan 21
13:25:05 2019
@@ -137,7 +137,81 @@
<networkConnector
uri="masterslave:(tcp://host1:61616,tcp://host2:61616,tcp://..)"/>
</networkConnectors>
</pre>
-</div></div><p>The URIs are listed in order for:
MASTER,SLAVE1,SLAVE2...SLAVE<img class="emoticon emoticon-thumbs-down"
title="(thumbs down)" border="0"
src="https://cwiki.apache.org/confluence/s/en_GB/7701/d7b403a44466e5e8970db7530201039d865e79e1/_/images/icons/emoticons/thumbs_down.svg";
alt="(thumbs down)"></p><p>The same configuration options for
<code>static:</code> are available for <code>masterslave:</code></p><h2
id="NetworksofBrokers-NetworkConnectorProperties">NetworkConnector
Properties</h2><div class="table-wrap"><table class="confluenceTable"><colgroup
span="1"><col span="1"><col span="1"><col span="1"></colgroup><tbody><tr><th
colspan="1" rowspan="1" class="confluenceTh"><p>property</p></th><th
colspan="1" rowspan="1" class="confluenceTh"><p>default</p></th><th colspan="1"
rowspan="1" class="confluenceTh"><p>description</p></th></tr><tr><td
colspan="1" rowspan="1" class="confluenceTd"><p>name</p></td><td colspan="1"
rowspan="1" class="confluenceTd"><p>bridge</p></td><td
colspan="1" rowspan="1" class="confluenceTd"><p>name of the network - for
more than one network connector between the same two brokers - use different
names</p></td></tr><tr><td colspan="1" rowspan="1"
class="confluenceTd"><p>dynamicOnly</p></td><td colspan="1" rowspan="1"
class="confluenceTd"><p>false</p></td><td colspan="1" rowspan="1"
class="confluenceTd"><p>if true, only activate a networked durable subscription
when a corresponding durable subscription reactivates, by default they are
activated on startup.</p></td></tr><tr><td colspan="1" rowspan="1"
class="confluenceTd"><p>decreaseNetworkConsumerPriority</p></td><td colspan="1"
rowspan="1" class="confluenceTd"><p>false</p></td><td colspan="1" rowspan="1"
class="confluenceTd"><p>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</p></td></t
r><tr><td colspan="1" rowspan="1"
class="confluenceTd"><p>networkTTL</p></td><td colspan="1" rowspan="1"
class="confluenceTd"><p>1</p></td><td colspan="1" rowspan="1"
class="confluenceTd"><p>the number of brokers in the network that messages and
subscriptions can pass through (sets both message&consumer
-TTL)</p></td></tr><tr><td colspan="1" rowspan="1"
class="confluenceTd"><p>messageTTL</p></td><td colspan="1" rowspan="1"
class="confluenceTd"><p>1</p></td><td colspan="1" rowspan="1"
class="confluenceTd"><p>(version 5.9) the number of brokers in the network that
messages can pass through</p></td></tr><tr><td colspan="1" rowspan="1"
class="confluenceTd"><p>consumerTTL</p></td><td colspan="1" rowspan="1"
class="confluenceTd"><p>1</p></td><td colspan="1" rowspan="1"
class="confluenceTd"><p>(version 5.9) the number of brokers in the network that
subscriptions can pass through (keep to 1 in a mesh)</p></td></tr><tr><td
colspan="1" rowspan="1" class="confluenceTd"><p>conduitSubscripti
ons</p></td><td colspan="1" rowspan="1"
class="confluenceTd"><p>true</p></td><td colspan="1" rowspan="1"
class="confluenceTd"><p>multiple consumers subscribing to the same destination
are treated as one consumer by the network</p></td></tr><tr><td colspan="1"
rowspan="1" class="confluenceTd"><p>excludedDestinations</p></td><td
colspan="1" rowspan="1" class="confluenceTd"><p>empty</p></td><td colspan="1"
rowspan="1" class="confluenceTd"><p>destinations matching this list won't be
forwarded across the network (this only applies to
<span>dynamicallyIncludedDestinations)</span></p></td></tr><tr><td colspan="1"
rowspan="1" class="confluenceTd"><p>dynamicallyIncludedDestinations</p></td><td
colspan="1" rowspan="1" class="confluenceTd"><p>empty</p></td><td colspan="1"
rowspan="1" class="confluenceTd"><p>destinations that match this list
<strong>will</strong> be forwarded across the network <strong>n.b.</strong> an
empty list means all destinations not in the exluded list will be forwarded<
/p></td></tr><tr><td colspan="1" rowspan="1"
class="confluenceTd"><p>useVirtualDestSubs</p></td><td colspan="1" rowspan="1"
class="confluenceTd"><p>false</p></td><td colspan="1" rowspan="1"
class="confluenceTd"><p>if true, the network connection will listen to advisory
messages for virtual destination consumers</p></td></tr><tr><td colspan="1"
rowspan="1" class="confluenceTd"><p>staticallyIncludedDestinations</p></td><td
colspan="1" rowspan="1" class="confluenceTd"><p>empty</p></td><td colspan="1"
rowspan="1" class="confluenceTd"><p>destinations that match will always be
passed across the network - even if no consumers have ever registered an
interest</p></td></tr><tr><td colspan="1" rowspan="1"
class="confluenceTd"><p>duplex</p></td><td colspan="1" rowspan="1"
class="confluenceTd"><p>false</p></td><td colspan="1" rowspan="1"
class="confluenceTd"><p>if true, a network connection will be used to both
produce <strong><em>AND</em></strong> Consume messages. This is useful for hub
and s
poke scenarios when the hub is behind a firewall etc.</p></td></tr><tr><td
colspan="1" rowspan="1" class="confluenceTd"><p>prefetchSize</p></td><td
colspan="1" rowspan="1" class="confluenceTd"><p>1000</p></td><td colspan="1"
rowspan="1" class="confluenceTd"><p>Sets the <a shape="rect"
href="what-is-the-prefetch-limit-for.html">prefetch size</a> on the network
connector's consumer. It must be > 0 because network consumers do not poll
for messages</p></td></tr><tr><td colspan="1" rowspan="1"
class="confluenceTd"><p>suppressDuplicateQueueSubscriptions</p></td><td
colspan="1" rowspan="1" class="confluenceTd"><p>false</p></td><td colspan="1"
rowspan="1" class="confluenceTd"><p>(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.</p></td></tr><tr><td colspan="1" rowspan="1"
class="confluenceTd"><p>bridgeTempDestinations</p></td><td colspan="1"
rowspan="1" class="confluenceTd"><p>true</p></td><td colspan="1" rowspan="1"
class="confluenceTd"><p>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 networ
k 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). <br clear="none"> 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.</p></td></tr><tr><td colspan="1" rowspan="1"
class="confluenceTd"><p>alwaysSyncSend</p></td><td colspan="1" rowspan="1"
class="confluenceTd"><p>false</p></td><td colspan="1" rowspan="1"
class="confluenceTd"><p>(version 5.6) Whe
n 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.</p></td></tr><tr><td colspan="1" rowspan="1"
class="confluenceTd"><p>staticBridge</p></td><td colspan="1" rowspan="1"
class="confluenceTd"><p>false</p></td><td colspan="1" rowspan="1"
class="confluenceTd"><p>(version 5.6) If set to true, broker will not
dynamically respond to new consumers. It will only use
<code>staticallyIncludedDestinations</code> to create demand
subscriptions</p></td></tr><tr><td colspan="1" rowspan="1"
class="confluenceTd">userName</td><td colspan="1" rowspan="1"
class="confluenceTd">null</td><td colspan="1" rowspan="1"
class="confluenceTd">The username to authenticate against the remote
broker</td></tr><tr><td colspan="1" rowspan="1"
class="confluenceTd">password</td><td colspan="1" rowspan="1"
class="confluenceTd">null</td><td colspan="1" rowspan="1"
class="confluenceTd">The password
for the username to authenticate against the remote broker</td></tr><tr><td
colspan="1" rowspan="1" class="confluenceTd">sslContext</td><td colspan="1"
rowspan="1" class="confluenceTd">null</td><td colspan="1" rowspan="1"
class="confluenceTd">The sslContext to use, overriding the brokerService or JVM
ssl defaults (5.16.0)</td></tr></tbody></table></div><h4
id="NetworksofBrokers-Reliability">Reliability</h4><p>Networks of brokers do
reliable store and forward of messages. If the source is durable, persistent
messages on a queue or a durable topic subscription, a network will retain the
durability guarantee. <br clear="none"> However networks cannot add durability
when the source is non durable. Non durable topic subscriptions and temporary
destinations (both queues and topics) are non durable by definition. When non
durable<br clear="none"> sources are networked, in the event of a failure,
inflight messages can be lost.</p><h4
id="NetworksofBrokers-Ordering">Ordering</h4><p>Total me
ssage ordering is not preserved with networks of brokers. Total ordering <a
shape="rect" href="how-do-i-preserve-order-of-messages.html">works with a
single consumer</a> but a networkBridge introduces a second consumer. In
addition, network bridge consumers forward messages via producer.send(..), so
they go from the head of the queue on the forwarding broker to the tail of the
queue on the target. If single consumer moves between networked brokers, total
order may be preserved if all messages always follow the consumer but this can
be difficult to guarantee with large message backlogs.</p><h4
id="NetworksofBrokers-WhentouseandnotuseConduitsubscriptions">When to use and
not use Conduit subscriptions</h4><p>ActiveMQ relies on information about
active consumers (subscriptions) to pass messages around the network. A broker
interprets a subscription from a remote (networked) broker in the same way as
it would a subscription from a local client connection and routes a copy of any
relevant
message to each subscription. With Topic subscriptions and with more than one
remote subscription, a remote broker would interpret each message copy as
valid, so when it in turns routes the messages to its own local connections,
duplicates would occur. Hence default conduit behavior consolidates all
matching subscription information to prevent duplicates flowing around the
network. With this default behaviour, N subscriptions on a remote broker look
like a single subscription to the networked broker.</p><p>However - duplicate
subscriptions is a useful feature to exploit if you are only using Queues. As
the load balancing algorithm will attempt to share message load evenly,
consumers across a network will equally share the message load only if the flag
<code>conduitSubscriptions=false</code>. Here's an example. Suppose you have
two brokers, A and B, that are connected to one another via a forwarding
bridge. Connected to broker A, you have a consumer that subscribes to a queue
called
<code>Q.TEST</code>. Connected to broker B, you have two consumers that also
subscribe to <code>Q.TEST</code>. All consumers have equal priority. Then you
start a producer on broker A that writes 30 messages to <code>Q.TEST</code>. By
default, (<code>conduitSubscriptions=true</code>), 15 messages will be sent to
the consumer on broker A and the resulting 15 messages will be sent to the two
consumers on broker B. The message load has not been equally spread across all
three consumers because, by default, broker A views the two subscriptions on
broker B as one. If you had set <code>conduitSubscriptions</code>
to <code>false</code>, then each of the three consumers would have been
given 10 messages.</p><h4 id="NetworksofBrokers-Duplexnetworkconnectors">Duplex
network connectors</h4><p>By default a network bridge forwards messages on
demand in one direction over a single connection. When
<code>duplex=true</code>, the same connection is used for a network bridge in
the opposite dir
ections, resulting in a bi-directional bridge. The network bridge
configuration is propagated to the other broker so the duplex bridge is an
exact replica or the original.</p><p><br clear="none"> Given two brokers,
broker A and broker B, a duplex bridge on A to B is the same as a default
bridge on A to B and a default bridge on B to A.</p><p><br clear="none"> Note,
if you want to configure more than one duplex network bridge between two
brokers, to increase throughput or to partition topics and queues, you must
provide unique names for each:</p><div class="code panel pdl"
style="border-width: 1px;"><div class="codeContent panelContent pdl">
+</div></div><p>The URIs are listed in order for:
MASTER,SLAVE1,SLAVE2...SLAVE<img class="emoticon emoticon-thumbs-down"
title="(thumbs down)" border="0"
src="https://cwiki.apache.org/confluence/s/en_GB/7701/d7b403a44466e5e8970db7530201039d865e79e1/_/images/icons/emoticons/thumbs_down.svg";
alt="(thumbs down)"></p><p>The same configuration options for
<code>static:</code> are available for <code>masterslave:</code></p><h2
id="NetworksofBrokers-NetworkConnectorProperties">NetworkConnector
Properties</h2><div class="table-wrap"><table class="confluenceTable"><colgroup
span="1"><col span="1"><col span="1"><col span="1"></colgroup><tbody><tr><th
colspan="1" rowspan="1" class="confluenceTh"><p>property</p></th><th
colspan="1" rowspan="1" class="confluenceTh"><p>default</p></th><th colspan="1"
rowspan="1" class="confluenceTh"><p>description</p></th></tr><tr><td
colspan="1" rowspan="1" class="confluenceTd"><p>name</p></td><td colspan="1"
rowspan="1" class="confluenceTd"><p>bridge</p></td><td
colspan="1" rowspan="1" class="confluenceTd"><p>name of the network - for
more than one network connector between the same two brokers - use different
names</p></td></tr><tr><td colspan="1" rowspan="1"
class="confluenceTd"><p>dynamicOnly</p></td><td colspan="1" rowspan="1"
class="confluenceTd"><p>false</p></td><td colspan="1" rowspan="1"
class="confluenceTd"><p>if true, only activate a networked durable subscription
when a corresponding durable subscription reactivates, by default they are
activated on startup.</p></td></tr><tr><td colspan="1" rowspan="1"
class="confluenceTd"><p>decreaseNetworkConsumerPriority</p></td><td colspan="1"
rowspan="1" class="confluenceTd"><p>false</p></td><td colspan="1" rowspan="1"
class="confluenceTd"><p>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</p></td></t
r><tr><td colspan="1" rowspan="1"
class="confluenceTd"><p>networkTTL</p></td><td colspan="1" rowspan="1"
class="confluenceTd"><p>1</p></td><td colspan="1" rowspan="1"
class="confluenceTd"><p>the number of brokers in the network that messages and
subscriptions can pass through (sets both message&consumer
-TTL)</p></td></tr><tr><td colspan="1" rowspan="1"
class="confluenceTd"><p>messageTTL</p></td><td colspan="1" rowspan="1"
class="confluenceTd"><p>1</p></td><td colspan="1" rowspan="1"
class="confluenceTd"><p>(version 5.9) the number of brokers in the network that
messages can pass through</p></td></tr><tr><td colspan="1" rowspan="1"
class="confluenceTd"><p>consumerTTL</p></td><td colspan="1" rowspan="1"
class="confluenceTd"><p>1</p></td><td colspan="1" rowspan="1"
class="confluenceTd"><p>(version 5.9) the number of brokers in the network that
subscriptions can pass through (keep to 1 in a mesh)</p></td></tr><tr><td
colspan="1" rowspan="1" class="confluenceTd"><p>conduitSubscripti
ons</p></td><td colspan="1" rowspan="1"
class="confluenceTd"><p>true</p></td><td colspan="1" rowspan="1"
class="confluenceTd"><p>multiple consumers subscribing to the same destination
are treated as one consumer by the network</p></td></tr><tr><td colspan="1"
rowspan="1" class="confluenceTd"><p>excludedDestinations</p></td><td
colspan="1" rowspan="1" class="confluenceTd"><p>empty</p></td><td colspan="1"
rowspan="1" class="confluenceTd"><p>destinations matching this list won't be
forwarded across the network (this only applies to
<span>dynamicallyIncludedDestinations)</span></p></td></tr><tr><td colspan="1"
rowspan="1" class="confluenceTd"><p>dynamicallyIncludedDestinations</p></td><td
colspan="1" rowspan="1" class="confluenceTd"><p>empty</p></td><td colspan="1"
rowspan="1" class="confluenceTd"><div class="content-wrapper"><p>destinations
that match this list <strong>will</strong> be forwarded across the network
<strong>n.b.</strong> an empty list means all destinations not in the ex
cluded 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 <style>
+ .jira-issue {
+ padding: 0 0 0 2px;
+ line-height: 20px;
+ }
+
+ .jira-issue img {
+ padding-right: 5px;
+ }
+
+ .jira-issue .aui-lozenge {
+ line-height: 18px;
+ vertical-align: top;
+ }
+
+ .jira-issue .icon {
+ background-position: left center;
+ background-repeat: no-repeat;
+ display: inline-block;
+ font-size: 0;
+ max-height: 16px;
+ text-align: left;
+ text-indent: -9999em;
+ vertical-align: text-bottom;
+ }
+</style>
+
+<span class="jira-issue" data-jira-key="AMQ-6383">
+ <a shape="rect" class="jira-issue-key"
href="https://issues.apache.org/jira/browse/AMQ-6383?src=confmacro";><img
class="icon" src="$iconUrl">AMQ-6383</a>
+ -
+ <span class="summary"></span>
+ <span class="jira-status">
+ (
+ <img class="icon" src="$statusIcon">
+ )
+ </span>
+ </span>
+</p></div></td></tr><tr><td colspan="1" rowspan="1"
class="confluenceTd"><p>useVirtualDestSubs</p></td><td colspan="1" rowspan="1"
class="confluenceTd"><p>false</p></td><td colspan="1" rowspan="1"
class="confluenceTd"><p>if true, the network connection will listen to advisory
messages for virtual destination consumers</p></td></tr><tr><td colspan="1"
rowspan="1" class="confluenceTd"><p>staticallyIncludedDestinations</p></td><td
colspan="1" rowspan="1" class="confluenceTd"><p>empty</p></td><td colspan="1"
rowspan="1" class="confluenceTd"><div class="content-wrapper"><p>destinations
that match will always be passed across the network - even if no consumers have
ever registered an interest. <span>Starting with version 5.14.0 the flag
</span><span>forceDurable can be appended to a topic which will ensure the
subscription between the two brokers is always a durable subscription. See
</span><style>
+ .jira-issue {
+ padding: 0 0 0 2px;
+ line-height: 20px;
+ }
+
+ .jira-issue img {
+ padding-right: 5px;
+ }
+
+ .jira-issue .aui-lozenge {
+ line-height: 18px;
+ vertical-align: top;
+ }
+
+ .jira-issue .icon {
+ background-position: left center;
+ background-repeat: no-repeat;
+ display: inline-block;
+ font-size: 0;
+ max-height: 16px;
+ text-align: left;
+ text-indent: -9999em;
+ vertical-align: text-bottom;
+ }
+</style>
+
+<span class="jira-issue" data-jira-key="AMQ-6383">
+ <a shape="rect" class="jira-issue-key"
href="https://issues.apache.org/jira/browse/AMQ-6383?src=confmacro";><img
class="icon" src="$iconUrl">AMQ-6383</a>
+ -
+ <span class="summary"></span>
+ <span class="jira-status">
+ (
+ <img class="icon" src="$statusIcon">
+ )
+ </span>
+ </span>
+<span> </span></p></div></td></tr><tr><td colspan="1" rowspan="1"
class="confluenceTd"><p>duplex</p></td><td colspan="1" rowspan="1"
class="confluenceTd"><p>false</p></td><td colspan="1" rowspan="1"
class="confluenceTd"><p>if true, a network connection will be used to both
produce <strong><em>AND</em></strong> Consume messages. This is useful for hub
and spoke scenarios when the hub is behind a firewall etc.</p></td></tr><tr><td
colspan="1" rowspan="1" class="confluenceTd"><p>prefetchSize</p></td><td
colspan="1" rowspan="1" class="confluenceTd"><p>1000</p></td><td colspan="1"
rowspan="1" class="confluenceTd"><p>Sets the <a shape="rect"
href="what-is-the-prefetch-limit-for.html">prefetch size</a> on the network
connector's consumer. It must be > 0 because network consumers do not poll
for messages</p></td></tr><tr><td colspan="1" rowspan="1"
class="confluenceTd"><p>suppressDuplicateQueueSubscriptions</p></td><td
colspan="1" rowspan="1" class="confluenceTd"><p>false</p></td><td col
span="1" rowspan="1" class="confluenceTd"><p>(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.</p></td></tr><tr><td colspan="1" rowspan="1"
class="confluenceTd"><p>bridgeTempDestinations</p></td><td colspan="1"
rowspan="1" class="confluenceTd"><p>true</p></td><td colspan="1" rowspan="1"
class="
confluenceTd"><p>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). <br clear="none"> 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 anothe
r broker in your network) won't be able to send the reply message but instead
raise a "temp destination does not exist" exception.</p></td></tr><tr><td
colspan="1" rowspan="1" class="confluenceTd"><p>alwaysSyncSend</p></td><td
colspan="1" rowspan="1" class="confluenceTd"><p>false</p></td><td colspan="1"
rowspan="1" class="confluenceTd"><p>(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.</p></td></tr><tr><td colspan="1" rowspan="1"
class="confluenceTd"><p>staticBridge</p></td><td colspan="1" rowspan="1"
class="confluenceTd"><p>false</p></td><td colspan="1" rowspan="1"
class="confluenceTd"><p>(version 5.6) If set to true, broker will not
dynamically respond to new consumers. It will only use
<code>staticallyIncludedDestinations</code> to create demand
subscriptions</p></td></tr><tr><td colspan="1" rowspan="1"
class="confluenceTd">userName</t
d><td colspan="1" rowspan="1" class="confluenceTd">null</td><td colspan="1"
rowspan="1" class="confluenceTd">The username to authenticate against the
remote broker</td></tr><tr><td colspan="1" rowspan="1"
class="confluenceTd">password</td><td colspan="1" rowspan="1"
class="confluenceTd">null</td><td colspan="1" rowspan="1"
class="confluenceTd">The password for the username to authenticate against the
remote broker</td></tr><tr><td colspan="1" rowspan="1"
class="confluenceTd">sslContext</td><td colspan="1" rowspan="1"
class="confluenceTd">null</td><td colspan="1" rowspan="1"
class="confluenceTd">The sslContext to use, overriding the brokerService or JVM
ssl defaults (5.16.0)</td></tr></tbody></table></div><h4
id="NetworksofBrokers-Reliability">Reliability</h4><p>Networks of brokers do
reliable store and forward of messages. If the source is durable, persistent
messages on a queue or a durable topic subscription, a network will retain the
durability guarantee. <br clear="none"> Howeve
r networks cannot add durability when the source is non durable. Non durable
topic subscriptions and temporary destinations (both queues and topics) are non
durable by definition. When non durable<br clear="none"> sources are networked,
in the event of a failure, inflight messages can be lost.</p><h4
id="NetworksofBrokers-Ordering">Ordering</h4><p>Total message ordering is not
preserved with networks of brokers. Total ordering <a shape="rect"
href="how-do-i-preserve-order-of-messages.html">works with a single
consumer</a> but a networkBridge introduces a second consumer. In addition,
network bridge consumers forward messages via producer.send(..), so they go
from the head of the queue on the forwarding broker to the tail of the queue on
the target. If single consumer moves between networked brokers, total order may
be preserved if all messages always follow the consumer but this can be
difficult to guarantee with large message backlogs.</p><h4
id="NetworksofBrokers-Whentouseandnotus
eConduitsubscriptions">When to use and not use Conduit
subscriptions</h4><p>ActiveMQ relies on information about active consumers
(subscriptions) to pass messages around the network. A broker interprets a
subscription from a remote (networked) broker in the same way as it would a
subscription from a local client connection and routes a copy of any relevant
message to each subscription. With Topic subscriptions and with more than one
remote subscription, a remote broker would interpret each message copy as
valid, so when it in turns routes the messages to its own local connections,
duplicates would occur. Hence default conduit behavior consolidates all
matching subscription information to prevent duplicates flowing around the
network. With this default behaviour, N subscriptions on a remote broker look
like a single subscription to the networked broker.</p><p>However - duplicate
subscriptions is a useful feature to exploit if you are only using Queues. As
the load balancing algorithm
will attempt to share message load evenly, consumers across a network will
equally share the message load only if the flag
<code>conduitSubscriptions=false</code>. Here's an example. Suppose you have
two brokers, A and B, that are connected to one another via a forwarding
bridge. Connected to broker A, you have a consumer that subscribes to a queue
called <code>Q.TEST</code>. Connected to broker B, you have two consumers that
also subscribe to <code>Q.TEST</code>. All consumers have equal priority. Then
you start a producer on broker A that writes 30 messages to
<code>Q.TEST</code>. By default, (<code>conduitSubscriptions=true</code>), 15
messages will be sent to the consumer on broker A and the resulting 15 messages
will be sent to the two consumers on broker B. The message load has not been
equally spread across all three consumers because, by default, broker A views
the two subscriptions on broker B as one. If you had set
<code>conduitSubscriptions</code> to <code>false</co
de>, then each of the three consumers would have been given 10
messages.</p><h4 id="NetworksofBrokers-Duplexnetworkconnectors">Duplex network
connectors</h4><p>By default a network bridge forwards messages on demand in
one direction over a single connection. When <code>duplex=true</code>, the same
connection is used for a network bridge in the opposite directions, resulting
in a bi-directional bridge. The network bridge configuration is propagated to
the other broker so the duplex bridge is an exact replica or the
original.</p><p><br clear="none"> Given two brokers, broker A and broker B, a
duplex bridge on A to B is the same as a default bridge on A to B and a default
bridge on B to A.</p><p><br clear="none"> Note, if you want to configure more
than one duplex network bridge between two brokers, to increase throughput or
to partition topics and queues, you must provide unique names for each:</p><div
class="code panel pdl" style="border-width: 1px;"><div class="codeContent
panelCont
ent pdl">
<pre class="brush: java; gutter: false; theme:
Default"><networkConnectors>
<networkConnector name="SYSTEM1" duplex="true"
uri="static:(tcp://10.x.x.x:61616)">
<dynamicallyIncludedDestinations>
![https://cwiki.apache.org/confluence/s/en_GB/7701/d7b403a44466e5e8970db7530201039d865e79e1/_/images/icons/emoticons/thumbs_down.svg"](https://cwiki.apache.org/confluence/s/en_GB/7701/d7b403a44466e5e8970db7530201039d865e79e1/_/images/icons/emoticons/thumbs_down.svg"){kind=link}