Author: buildbot
Date: Thu Feb 11 14:21:52 2016
New Revision: 980137
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 Feb 11
14:21:52 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">useV
irtualDestSubs</td><td colspan="1" rowspan="1"
class="confluenceTd">false</td><td colspan="1" rowspan="1"
class="confluenceTd">if true, the network connection will listen to advisory
messages for virtual destination consumers</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" rows
pan="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 (b
eing 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 he
ader. 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 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></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="n
one"> 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 sub
scription 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 bro
kers, 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></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">
<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}