Author: buildbot
Date: Mon Aug 20 17:25:06 2018
New Revision: 1034226
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 Aug 20
17:25:06 2018
@@ -83,7 +83,7 @@
<tr>
<td valign="top" width="100%">
<div class="wiki-content maincontent"><p>To provide massive scalability of a
large messaging fabric you typically want to allow many brokers to be connected
together into a network so that you can have as many clients as you wish all
logically connected together - and running as many message brokers as you need
based on your number of clients and network topology.</p><p>If you are using <a
shape="rect" href="topologies.html">client/server or hub/spoke style
topology</a> then the broker you connect to becomes a single point of failure
which is another reason for wanting a network (or cluster) of brokers so that
you can survive failure of any particular broker, machine or subnet.</p><p>From
1.1 onwards of ActiveMQ supports <em>networks of brokers</em> which allows us
to support <a shape="rect"
href="how-do-distributed-queues-work.html">distributed queues and topics</a>
across a network of brokers.</p><p>This allows a client to connect to any
broker in the network - and fail over to an
other broker if there is a failure - providing from the clients perspective a
<a shape="rect" href="ha.html">HA</a> cluster of
brokers.</p><p><strong>N.B.</strong> By default a network connection is one way
only - the broker that establishes the connection <em>passes messages to</em>
the broker(s) its connected to. From version 5.x of ActiveMQ, a network
connection can be optionally enabled to be duplex, which can be useful for hub
and spoke architectures, where the hub is behind a firewall etc.</p><h2
id="NetworksofBrokers-Configuringanetworkofbrokers">Configuring a network of
brokers</h2><p>The easiest way to configure a network of brokers is via the <a
shape="rect" href="xml-configuration.html">Xml Configuration</a>. There are two
main ways to create a network of brokers</p><ul><li>use a hard coded list of
networkConnector elements.</li></ul><ul><li>use Discovery to detect brokers
(multicast or rendezvous).</li></ul><h3
id="NetworksofBrokers-ExamplewithafixedlistofURIs">Example w
ith a fixed list of URIs</h3><p>Here is an example of using the fixed list of
URIs</p><div class="code panel pdl" style="border-width: 1px;"><div
class="codeContent panelContent pdl">
-<pre class="brush: java; gutter: false; theme: Default"
style="font-size:12px;"><?xml version="1.0" encoding="UTF-8"?>
+<pre class="brush: java; gutter: false; theme: Default"><?xml version="1.0"
encoding="UTF-8"?>
<beans xmlns="http://activemq.org/config/1.0">
@@ -104,7 +104,7 @@
</beans>
</pre>
</div></div><p>ActiveMQ also supports other transports than tcp to be used for
the network connector such as http.</p><h3
id="NetworksofBrokers-Exampleusingmulticastdiscovery">Example using multicast
discovery</h3><p>This example uses multicast <a shape="rect"
class="external-link"
href="http://activemq.apache.org/discovery.html";>discovery</a></p><div
class="code panel pdl" style="border-width: 1px;"><div class="codeContent
panelContent pdl">
-<pre class="brush: java; gutter: false; theme: Default"
style="font-size:12px;"><?xml version="1.0" encoding="UTF-8"?>
+<pre class="brush: java; gutter: false; theme: Default"><?xml version="1.0"
encoding="UTF-8"?>
<beans xmlns="http://activemq.org/config/1.0">
@@ -125,20 +125,20 @@
</beans>
</pre>
</div></div><h2 id="NetworksofBrokers-Startingnetworkconnectors">Starting
network connectors</h2><p>By default, network connectors are initiated serially
as part of the broker start up sequence. When some networks are slow, they
prevent other networks from starting in a timely manner. Version 5.5 supports
the broker attribute networkConnectorStartAsync="true" which will cause the
broker to use an executor to start network connectors in parallel, asynchronous
to a broker start.</p><h2 id="NetworksofBrokers-Staticdiscovery">Static
discovery</h2><p>With <code>static:</code> discovery you can hard code the list
of broker URLs. A network connector will be created for each one.</p><div
class="code panel pdl" style="border-width: 1px;"><div class="codeContent
panelContent pdl">
-<pre class="brush: java; gutter: false; theme: Default"
style="font-size:12px;"> <networkConnectors>
+<pre class="brush: java; gutter: false; theme: Default">
<networkConnectors>
<networkConnector
uri="static:(tcp://host1:61616,tcp://host2:61616,tcp://..)"/>
</networkConnectors>
</pre>
</div></div><p>There are some useful properties you can set on a static
network connector for retries:</p><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>initialReconnectDelay</p></td><td
colspan="1" rowspan="1" class="confluenceTd"><p>1000</p></td><td colspan="1"
rowspan="1" class="confluenceTd"><p>time(ms) to wait before attempting a
reconnect (if useExponentialBackOff is false)</p></td></tr><tr><td colspan="1"
rowspan="1" class="confluenceTd"><p>maxReconnectDelay</p></td><td colspan="1"
rowspan="1" class="confluenceTd"><p>30000</p></td><td colspan="1" rowspan="1"
class="confluenceTd"><p>time(ms) to wait before attempting to
re-connect</p></td></tr><tr><td colspan="1" rowspan="1" class="confluenceT
d"><p>useExponentialBackOff</p></td><td colspan="1" rowspan="1"
class="confluenceTd"><p>true</p></td><td colspan="1" rowspan="1"
class="confluenceTd"><p>increases time between reconnect for every failure in a
reconnect sequence</p></td></tr><tr><td colspan="1" rowspan="1"
class="confluenceTd"><p>backOffMultiplier</p></td><td colspan="1" rowspan="1"
class="confluenceTd"><p>2</p></td><td colspan="1" rowspan="1"
class="confluenceTd"><p>multipler used to increase the wait time if using
exponential back off</p></td></tr></tbody></table></div><p>e.g.</p><div
class="code panel pdl" style="border-width: 1px;"><div class="codeContent
panelContent pdl">
-<pre class="brush: java; gutter: false; theme: Default"
style="font-size:12px;">uri="static:(tcp://host1:61616,tcp://host2:61616)?maxReconnectDelay=5000&useExponentialBackOff=false"
+<pre class="brush: java; gutter: false; theme:
Default">uri="static:(tcp://host1:61616,tcp://host2:61616)?maxReconnectDelay=5000&useExponentialBackOff=false"
</pre>
</div></div><h2 id="NetworksofBrokers-MasterSlaveDiscovery">MasterSlave
Discovery</h2><p>A common configuration option for a network of brokers is to
establish a network bridge between a broker and an n+1 broker pair
(master/slave). Typical configurations involve using the <code>failover:</code>
transport, but there are a some other non-intuitive options that must be
configured for it to work as desired. For this reason, ActiveMQ v5.6+ has a
convenience discovery agent that can be specified with the
<code>masterslave:</code> transport prefix:</p><div class="code panel pdl"
style="border-width: 1px;"><div class="codeContent panelContent pdl">
-<pre class="brush: java; gutter: false; theme: Default"
style="font-size:12px;"> <networkConnectors>
+<pre class="brush: java; gutter: false; theme: Default">
<networkConnectors>
<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/5997/6f42626d00e36f53fe51440403446ca61552e2a2.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: java; gutter: false; theme: Default"
style="font-size:12px;"><networkConnectors>
+</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">
+<pre class="brush: java; gutter: false; theme:
Default"><networkConnectors>
<networkConnector name="SYSTEM1" duplex="true"
uri="static:(tcp://10.x.x.x:61616)">
<dynamicallyIncludedDestinations>
<topic physicalName="outgoing.System1" />
@@ -151,45 +151,45 @@
</networkConnector>
</networkConnectors></pre>
</div></div><h4
id="NetworksofBrokers-Conduitsubscriptionsandconsumerselectors">Conduit
subscriptions and consumer selectors</h4><p>Conduit subscriptions ignore
consumer selectors on the local broker and send all messages to the remote one.
Selectors are then parsed on the remote brokers before messages are dispatched
to consumers. This concept could create some problems with consuming on queues
using selectors in a multi-broker network. Imagine a situation when you have a
producing broker forwarding messages to two receiving brokers and each of these
two brokers have a consumer with different selector. Since no selectors are
evaluated on the producer broker side, you can end up with all messages going
to only one of the brokers, so messages with certain property will not be
consumed. If you need to support this use case, please turn off
<code>conduitSubscription</code> feature.</p><h4
id="NetworksofBrokers-ConfigurationPitfalls">Configuration Pitfalls</h4><div
class="confluence-inf
ormation-macro confluence-information-macro-warning"><span class="aui-icon
aui-icon-small aui-iconfont-error
confluence-information-macro-icon"></span><div
class="confluence-information-macro-body"><p>Networks do not work as expected
(they cannot dynamically respond to new consumers) if the
<code>advisorySupport</code> broker property is disabled. A fully statically
configured network is the only option if <code>advisorySupport</code> is
disabled. Read more about it in the following section.</p></div></div><h3
id="NetworksofBrokers-Networksofbrokersandadvisories">Networks of brokers and
advisories</h3><p>Network of brokers relies heavily on advisory messages, as
they are used under the hood to express interest in new consumers on the remote
end. By default, when network connector starts it defines one consumer on the
following topic <code>ActiveMQ.Advisory.Consumer.></code> (let's ignore
temporary destination for the moment). In this way, when consumer connects (or
disconnects) t
o the remote broker, the local broker will get notified and will treat it as
one more consumer it had to deal with.</p><p>This is all fine and well in small
networks and environments whit small number of destinations and consumers. But
as things starts to grow a default model (listen to everything, share
everything) won't scale well. That's why there are many ways you can use to
filter destinations that will be shared between brokers.</p><h4
id="NetworksofBrokers-Dynamicnetworks">Dynamic networks</h4><p>Let's start with
dynamically configured networks. This means that we only want to send messages
to the remote broker when there's a consumer there. If we want to limit this
behavior only on certain destinations we will use
<code>dynamicallyIncludedDestinations</code>, like</p><div class="code panel
pdl" style="border-width: 1px;"><div class="codeContent panelContent pdl">
-<pre class="brush: java; gutter: false; theme: Default"
style="font-size:12px;"><networkConnector uri="static:(tcp://host)">
+<pre class="brush: java; gutter: false; theme: Default"><networkConnector
uri="static:(tcp://host)">
<dynamicallyIncludedDestinations>
<queue physicalName="include.test.foo"/>
<topic physicalName="include.test.bar"/>
</dynamicallyIncludedDestinations>
</networkConnector></pre>
</div></div><p>In versions of ActiveMQ prior to 5.6, the broker would still
use the same advisory filter and express interest in all consumers on the
remote broker. The actual filtering will be done during message dispatch. This
is suboptimal solution in huge networks as it creates a lot of "advisory"
traffic and load on the brokers. Starting with version 5.6, the broker will
automatically create an appropriate advisory filter and express interest only
in dynamically included destinations. For our example it will be
"<code>ActiveMQ.Advisory.Consumer.Queue.include.test.foo,ActiveMQ.Advisory.Consumer.Topic.include.test.bar</code>".
This can dramatically improve behavior of the network in complex and high-load
environments.</p><p>In older broker versions we can achieve the same thing with
a slightly more complicated configuration. The actual advisory filter that
controls in which consumers we are interested is defined with the
<code>destinationFilter</code> connector property. Its defa
ult value is ">", which is concatenated to the
<code>"ActiveMQ.Advisory.Consumer."</code> prefix. So to achieve the same
thing, we would need to do the following:</p><div class="code panel pdl"
style="border-width: 1px;"><div class="codeContent panelContent pdl">
-<pre class="brush: java; gutter: false; theme: Default"
style="font-size:12px;"><networkConnector uri="static:(tcp://host)"
destinationFilter="Queue.include.test.foo,ActiveMQ.Advisory.Consumer.Topic.include.test.bar">
+<pre class="brush: java; gutter: false; theme: Default"><networkConnector
uri="static:(tcp://host)"
destinationFilter="Queue.include.test.foo,ActiveMQ.Advisory.Consumer.Topic.include.test.bar">
<dynamicallyIncludedDestinations>
<queue physicalName="include.test.foo"/>
<topic physicalName="include.test.bar"/>
</dynamicallyIncludedDestinations>
</networkConnector></pre>
</div></div><p>Note that first destination does not have the prefix because
it's already implied. It's a bit more complicated to set and maintain, but it
will work. And if you're using 5.6 or newer version of the broker just
including desired destinations with
<code>dynamicallyIncludedDestinations</code> should suffice.</p><p>This also
explains why dynamic networks do not work if you turn off advisory support on
the brokers. The brokers in this case cannot dynamically respond to new
consumers.</p><h4 id="NetworksofBrokers-Purestaticnetworks">Pure static
networks</h4><p>If you wish to completely protect the broker from any influence
of consumers on the remote broker, or if you wish to use the brokers as a
simple proxy and forward all messages to the remote side no matter if there are
consumers there or not, static networks are something you should
consider.</p><div class="code panel pdl" style="border-width: 1px;"><div
class="codeContent panelContent pdl">
-<pre class="brush: java; gutter: false; theme: Default"
style="font-size:12px;"><networkConnector uri="static:(tcp://host)"
staticBridge="true">
+<pre class="brush: java; gutter: false; theme: Default"><networkConnector
uri="static:(tcp://host)" staticBridge="true">
<staticallyIncludedDestinations>
<queue physicalName="always.include.queue"/>
</staticallyIncludedDestinations>
</networkConnector></pre>
</div></div><p>The <code>staticBridge</code> parameter is available since
version 5.6 and it means that the local broker will not subscribe to any
advisory topics on the remote broker, meaning it is not interested in whether
there are any consumers there. Additionally, you need to add a list of
destinations to <code>staticallyIncludedDestinations</code>. This will have the
same effect as having an additional consumer on the destinations so messages
will be forwarded to the remote broker as well. As there is no
<code>staticBridge</code> parameter in the earlier versions of ActiveMQ, you
can trick the broker by setting <code>destinationFilter</code> to listen to an
unused advisory topic, like</p><div class="code panel pdl" style="border-width:
1px;"><div class="codeContent panelContent pdl">
-<pre class="brush: java; gutter: false; theme: Default"
style="font-size:12px;"><networkConnector uri="static:(tcp://host)"
destinationFilter="NO_DESTINATION">
+<pre class="brush: java; gutter: false; theme: Default"><networkConnector
uri="static:(tcp://host)" destinationFilter="NO_DESTINATION">
<staticallyIncludedDestinations>
<queue physicalName="always.include.queue"/>
</staticallyIncludedDestinations>
</networkConnector></pre>
</div></div><p>If configured like this, broker will try to listen for new
consumers on <code>ActiveMQ.Advisory.Consumer.NO_DESTINATION</code>, which will
never have messages so it will be protected from information on remote broker
consumers.</p><h3
id="NetworksofBrokers-virtualconsumersDynamicnetworksandVirtualDestinations(Newfor5.13.0)"><span
class="confluence-anchor-link"
id="NetworksofBrokers-virtualconsumers"></span>Dynamic networks and Virtual
Destinations (New for 5.13.0)</h3><p>As described above, a network of brokers
can be configured to only send messages to a remote broker when there's a
consumer on an included destination.  However, let's consider some cases
of how dynamic flow occurs when <a shape="rect"
href="virtual-destinations.html">Virtual Destinations</a> are in
use.</p><h4
id="NetworksofBrokers-VirtualDestinationconsumersandCompositeDestinations">Virtual
Destination consumers and Composite Destinations</h4><p>Here is an example of
two brokers netwo
rked together.  The Local Broker contains the network connector
configured with a <code>dynamicallyIncludedDestination</code> and the
Remote Broker is configured with a CompositeTopic:</p><div class="code panel
pdl" style="border-width: 1px;"><div class="codeHeader panelHeader pdl"
style="border-bottom-width: 1px;"><b>Local Broker</b></div><div
class="codeContent panelContent pdl">
-<pre class="brush: xml; gutter: false; theme: Default"
style="font-size:12px;"><networkConnector uri="static:(tcp://host)">
+<pre class="brush: xml; gutter: false; theme: Default"><networkConnector
uri="static:(tcp://host)">
<dynamicallyIncludedDestinations>
<topic physicalName="include.bar"/>
</dynamicallyIncludedDestinations>
</networkConnector></pre>
</div></div><div class="code panel pdl" style="border-width: 1px;"><div
class="codeHeader panelHeader pdl" style="border-bottom-width: 1px;"><b>Remote
Broker</b></div><div class="codeContent panelContent pdl">
-<pre class="brush: xml; gutter: false; theme: Default"
style="font-size:12px;"><compositeTopic name="include.bar"
forwardOnly="false">
+<pre class="brush: xml; gutter: false; theme: Default"><compositeTopic
name="include.bar" forwardOnly="false">
<forwardTo>
<queue physicalName="include.bar.forward" />
</forwardTo>
</compositeTopic ></pre>
</div></div><p>In this example, let's consider a single consumer on the Remote
Broker on the queue <code>include.bar.forward</code>.  If a message is
sent directly to the Remote Broker on the topic <code>include.bar</code>,
it will be forwarded to the
queue <code>include.bar.forward</code> and the consumer will receive
it.  However, if a message is published to the same topic on the Local
Broker, this message will not be forwarded to the Remote Broker.</p><p>The
message is not forwarded because a consumer on
the <code>queue include.bar.forward</code> would not be detected
as part of the <code>dynamicallyIncludedDestinations</code> list in
the Local Broker.  Messages would not be forwarded to the Remote Broker
unless there was a consumer on the original topic as well (in this case
<code>include.bar</code>).  This can be fixed by configuring the Local
Broker to listen for Virtual Destination Subscriptions.  </p><p>F
irst, we need to configure the Remote Broker to send advisory messages when
consumers subscribe to a destination that matches a Virtual Destination.
 In this case, internally a match is determined through the use of a
Destination Filter that determines whether one destination forwards to another
destination.  To enable this, set the property
<code>useVirtualDestSubs</code> on the Remote Broker to
<code>true</code>:</p><div class="code panel pdl" style="border-width:
1px;"><div class="codeHeader panelHeader pdl" style="border-bottom-width:
1px;"><b>Remote Broker</b></div><div class="codeContent panelContent pdl">
-<pre class="brush: xml; gutter: false; theme: Default"
style="font-size:12px;"><?xml version="1.0" encoding="UTF-8"?>
+<pre class="brush: xml; gutter: false; theme: Default"><?xml version="1.0"
encoding="UTF-8"?>
<beans xmlns="http://activemq.org/config/1.0">
@@ -200,19 +200,19 @@
</beans>
</pre>
</div></div><p><br clear="none">Next, the network connector on the Local
Broker needs to be configured to listen for the new advisory messages by
setting the <code>useVirtualDestSubs</code> property to
<code>true</code>:</p><div class="code panel pdl" style="border-width:
1px;"><div class="codeHeader panelHeader pdl" style="border-bottom-width:
1px;"><b>Local Broker</b></div><div class="codeContent panelContent pdl">
-<pre class="brush: xml; gutter: false; theme: Default"
style="font-size:12px;"><networkConnector uri="static:(tcp://host)"
useVirtualDestSubs="true">
+<pre class="brush: xml; gutter: false; theme: Default"><networkConnector
uri="static:(tcp://host)" useVirtualDestSubs="true">
<dynamicallyIncludedDestinations>
<topic physicalName="include.bar"/>
</dynamicallyIncludedDestinations>
</networkConnector></pre>
</div></div><p>Now, if a consumer comes subscribes to the
queue <code>include.bar.forward</code> on the Remote Broker, the
Local Broker will forward messages that are sent to the
topic <code>include.bar.</code></p><h4
id="NetworksofBrokers-VirtualDestinationConsumersonDestinationCreation">Virtual
Destination Consumers on Destination Creation</h4><p>Now let's consider the use
case above where there is the same composite topic but no consumers on the
queue.<br clear="none"> </p><div class="code panel pdl"
style="border-width: 1px;"><div class="codeHeader panelHeader pdl"
style="border-bottom-width: 1px;"><b>Remote Broker</b></div><div
class="codeContent panelContent pdl">
-<pre class="brush: xml; gutter: false; theme: Default"
style="font-size:12px;"><compositeTopic name="include.bar"
forwardOnly="false">
+<pre class="brush: xml; gutter: false; theme: Default"><compositeTopic
name="include.bar" forwardOnly="false">
<forwardTo>
<queue physicalName="include.bar.forward" />
</forwardTo>
</compositeTopic ></pre>
</div></div><p>There is a Composite Topic configured on the Remote Broker, and
the Local Broker is networked to it.  </p><p>Even though we have enabled
<code>useVirtualDestSubs</code>, messages will not be forwarded to the Remote
Broker unless a consumer subscribes to the forwarded queue.  Without a
consumer, messages would be dropped as they are sent to a topic on the Local
Broker (<code>include.bar</code>).  In this situation it is desirable to
have messages forwarded based on the existence of a virtual destination that
forwards to:</p><ul><li>one or more queues; or</li><li>topics that have durable
subscriptions.</li></ul><p> </p><p>Both of these conditions are considered
as emitting demand for messages to the Local Broker, despite there being no
active consumers on those destinations.</p><p> </p><div class="code panel
pdl" style="border-width: 1px;"><div class="codeHeader panelHeader pdl"
style="border-bottom-width: 1px;"><b>Remote Broker</b></div><div cl
ass="codeContent panelContent pdl">
-<pre class="brush: xml; gutter: false; theme: Default"
style="font-size:12px;"><?xml version="1.0" encoding="UTF-8"?>
+<pre class="brush: xml; gutter: false; theme: Default"><?xml version="1.0"
encoding="UTF-8"?>
<beans xmlns="http://activemq.org/config/1.0">
@@ -222,13 +222,13 @@
</beans></pre>
</div></div><p>With this configuration, when the
queue <code>include.bar.forward</code> is created, a Virtual Destination
consumer advisory will be sent to the Local Broker so that it knows to forward
messages based on the existence of the Composite Topic that forwards to a
queue.</p><h4
id="NetworksofBrokers-CompositeDestinationconsumersandVirtualTopics">Composite
Destination consumers and Virtual Topics </h4><p>The above examples show
how to configure a Composite Destination but a Virtual Topic will also work.
 In the example below, a consumer on a queue for a Virtual Topic on the
Remote Broker will now cause demand and messages will be sent across a network
from the Local Broker.</p><div class="code panel pdl" style="border-width:
1px;"><div class="codeHeader panelHeader pdl" style="border-bottom-width:
1px;"><b>Local Broker</b></div><div class="codeContent panelContent pdl">
-<pre class="brush: xml; gutter: false; theme: Default"
style="font-size:12px;"><networkConnector uri="static:(tcp://host)">
+<pre class="brush: xml; gutter: false; theme: Default"><networkConnector
uri="static:(tcp://host)">
<dynamicallyIncludedDestinations>
<topic physicalName="VirtualTopic.>"/>
</dynamicallyIncludedDestinations>
</networkConnector></pre>
</div></div><div class="code panel pdl" style="border-width: 1px;"><div
class="codeHeader panelHeader pdl" style="border-bottom-width: 1px;"><b>Remote
Broker</b></div><div class="codeContent panelContent pdl">
-<pre class="brush: xml; gutter: false; theme: Default"
style="font-size:12px;"><?xml version="1.0" encoding="UTF-8"?>
+<pre class="brush: xml; gutter: false; theme: Default"><?xml version="1.0"
encoding="UTF-8"?>
<beans xmlns="http://activemq.org/config/1.0">
@@ -238,7 +238,7 @@
</beans></pre>
</div></div><h3
id="NetworksofBrokers-ExampleConfigurationusingNetworkConnectorproperties">Example
Configuration using NetworkConnector properties</h3><p>This part of an example
configuration for a Broker</p><div class="code panel pdl" style="border-width:
1px;"><div class="codeContent panelContent pdl">
-<pre class="brush: java; gutter: false; theme: Default"
style="font-size:12px;"><networkConnectors>
+<pre class="brush: java; gutter: false; theme:
Default"><networkConnectors>
<networkConnector uri="static:(tcp://localhost:61617)"
name="bridge"
conduitSubscriptions="true"
@@ -259,7 +259,7 @@
</networkConnectors>
</pre>
</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: java; gutter: false; theme: Default"
style="font-size:12px;"><networkConnectors>
+<pre class="brush: java; gutter: false; theme:
Default"><networkConnectors>
<networkConnector uri="static:(tcp://localhost:61617)"
name="queues_only"
conduitSubscriptions="false"
@@ -271,7 +271,7 @@
</networkConnectors>
</pre>
</div></div><p><strong>N.B.</strong> You can only use <a shape="rect"
href="wildcards.html">wildcards</a> in the <code>excludedDestinations</code>
and <code>dynamicallyIncludedDestinations</code> properties.<br clear="none">
<strong>N.B.</strong> <strong>Do not</strong> change the name of the bridge or
the name of the Broker if you are using durable topic subscribers across the
network. Internally ActiveMQ uses the network name and broker name to build a
unique but repeatable durable subscriber name for the network.</p><h3
id="NetworksofBrokers-StuckMessages">Stuck Messages</h3><p>By default, it is
not permissible for a message to be replayed back to the broker from which it
came. This ensures that messages do not loop when duplex or by directional
network connectors are configured. Occasionally it is desirable to allow replay
for queues. Consider a scenario where a bidirectional bridge exists between a
broker pair. Producers and Consumers get to randomly choose a broker using the f
ailover transport. If one broker is restarted for maintenance, messages
accumulated on that broker, that crossed the network bridge, will not be
available to consumers till they reconnect to the broker. One solution to this
problem is to force a client reconnect using <a shape="rect"
class="external-link"
href="http://activemq.apache.org/failover-transport-reference.html#FailoverTransportReference-BrokersideOptionsforFailover";>rebalanceClusterClients</a>.
Another, is to allow replay of messages back to the origin as there is no
local consumer on that broker. From version 5.16.0, using
<code>selectorAware=true</code> the replay can occur if there are no local
consumers who's selectors match the target message.<br clear="none"> There is a
destination policy that allows this behavior for queues by configuring a
<code>conditionalNetworkBridgeFilterFactory</code> with
<code>replayWhenNoConsumers=true</code>. The
<code>conditionalNetworkBridgeFilterFactory</code> provides an optional <cod
e>replayDelay</code> based on the broker-in time.</p><div class="code panel
pdl" style="border-width: 1px;"><div class="codeContent panelContent pdl">
-<pre class="brush: java; gutter: false; theme: Default"
style="font-size:12px;"> <destinationPolicy>
+<pre class="brush: java; gutter: false; theme: Default">
<destinationPolicy>
<policyMap>
<policyEntries>
<policyEntry queue="TEST.>" enableAudit="false">
![https://cwiki.apache.org/confluence/s/en_GB/5997/6f42626d00e36f53fe51440403446ca61552e2a2.1/_/images/icons/emoticons/thumbs_down.png"](https://cwiki.apache.org/confluence/s/en_GB/5997/6f42626d00e36f53fe51440403446ca61552e2a2.1/_/images/icons/emoticons/thumbs_down.png"){kind=link}
![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}