Author: buildbot
Date: Thu Aug 25 19:22:11 2016
New Revision: 995905
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 Thu Aug 25
19:22:11 2016
@@ -137,7 +137,7 @@
<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"
src="https://cwiki.apache.org/confluence/s/en_GB/5982/f2b47fb3d636c8bc9fd0b11c0ec6d0ae18646be7.1/_/images/icons/emoticons/thumbs_down.png";
data-emoticon-name="thumbs-down" 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"><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></tr><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>conduitSubscriptions</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>u
seVirtualDestSubs</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 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 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 bridg
es 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 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) When true, non persistent messages are
sent to the remote broker using re
quest/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></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 no
n 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-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 br
oker 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. Sup
pose 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 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 panelContent pdl">
+</div></div><p>The URIs are listed in order for:
MASTER,SLAVE1,SLAVE2...SLAVE<img class="emoticon emoticon-thumbs-down"
src="https://cwiki.apache.org/confluence/s/en_GB/5982/f2b47fb3d636c8bc9fd0b11c0ec6d0ae18646be7.1/_/images/icons/emoticons/thumbs_down.png";
data-emoticon-name="thumbs-down" 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"><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></tr><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>conduitSubscriptions</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>u
seVirtualDestSubs</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 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 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 bridg
es 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 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) When true, non persistent messages are
sent to the remote broker using re
quest/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><
/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 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-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 brok
er 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 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 panelContent pdl">
<pre class="brush: xml; gutter: false; theme: Default"
style="font-size:12px;"><networkConnectors>
<networkConnector name="SYSTEM1" duplex="true"
uri="static:(tcp://10.x.x.x:61616)">
<dynamicallyIncludedDestinations>
![https://cwiki.apache.org/confluence/s/en_GB/5982/f2b47fb3d636c8bc9fd0b11c0ec6d0ae18646be7.1/_/images/icons/emoticons/thumbs_down.png"](https://cwiki.apache.org/confluence/s/en_GB/5982/f2b47fb3d636c8bc9fd0b11c0ec6d0ae18646be7.1/_/images/icons/emoticons/thumbs_down.png"){kind=link}