activemq-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From build...@apache.org
Subject svn commit: r977596 - in /websites/production/activemq/content: cache/main.pageCache networks-of-brokers.html
Date Wed, 13 Jan 2016 12:22:29 GMT
Author: buildbot
Date: Wed Jan 13 12:22:29 2016
New Revision: 977596

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 Wed Jan 13 12:22:29 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&amp;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</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">useVirtualDestSubs</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" 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 &gt; 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 b
 e 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 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="none"> sources are networked, in the event
of a failure, inflight mes
 sages 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 wou
 ld 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 br
 idge. 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&#160;<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&amp;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 &gt; 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&#160;<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;">&lt;networkConnectors&gt;
         &lt;networkConnector name="SYSTEM1" duplex="true" uri="static:(tcp://10.x.x.x:61616)"&gt;
                 &lt;dynamicallyIncludedDestinations&gt;
@@ -258,7 +258,7 @@
       &lt;/networkConnector&gt;
     &lt;/networkConnectors&gt;
 </pre>
-</div></div><p>It is possible to have more than one network connector between
two brokers. Each network connector uses one underlying transport connection, so you may wish
to do this to increase throughput, or have a more flexible configuration.</p><p><br
clear="none"> For example, if using distributed queues, you may wish to have equivalent
weighting to queue receivers across the network, but only when the receivers are active -
e.g.</p><div class="code panel pdl" style="border-width: 1px;"><div class="codeContent
panelContent pdl">
+</div></div><p>Note that at the moment <code>excludedDestinations</code>
property doesn't affect <code>staticallyIncludedDestinations</code>.</p><p>It
is possible to have more than one network connector between two brokers. Each network connector
uses one underlying transport connection, so you may wish to do this to increase throughput,
or have a more flexible configuration.</p><p><br clear="none"> For example,
if using distributed queues, you may wish to have equivalent weighting to queue receivers
across the network, but only when the receivers are active - e.g.</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;">&lt;networkConnectors&gt;
       &lt;networkConnector uri="static:(tcp://localhost:61617)"
          name="queues_only"



Mime
View raw message