Author: buildbot
Date: Tue Nov 10 18:21:30 2015
New Revision: 972011
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 Tue Nov 10
18:21:30 2015
@@ -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</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>staticallyIncludedDestinations</p></td><td colspan="1"
rowspan="1" cl
ass="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 message
s</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 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 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 conduitSubscriptions=false. 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 Q.TEST. Connected to broker B, you have two consumers that
also subscribe to Q.TEST. All consumers have equal priority. Then you start a
producer on broker A that writes 30 messages to Q.TEST. By default,
(conduitSubscript
ions=true), 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 conduitSubscriptions to "false", 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 dupex=true, the same connection is
used for a network bridge in the opposite directions, resulting in a by
directional bridge. The network bridge configuration is propagated to the other
broker so the duplex bridge is an exact replica or the original.<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 bridg
e on B to A.<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:
eg:</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</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 > 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
conduitSubscriptions=false. Here's an example. Suppose you have two brokers, A
and B, that are connected to one another via a forwarding bridge. Connect
ed to broker A, you have a consumer that subscribes to a queue called Q.TEST.
Connected to broker B, you have two consumers that also subscribe to Q.TEST.
All consumers have equal priority. Then you start a producer on broker A that
writes 30 messages to Q.TEST. By default, (conduitSubscriptions=true), 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 conduitSubscriptions
to "false", 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 dupex=true, the same connection is
used for a network bridge in the opposite directions, resulting in a by
directional bridge. The network bridge configuration is propagated to the
other broker so the duplex bridge is an exact replica or the original.<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.<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: eg:</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>
@@ -176,7 +176,69 @@
<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-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">
+</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-DynamicnetworksandVirtualDestinations(Newfor5.13.0)">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 networked together.  The local broker contains the network
connector configured with a <code>dy
namicallyIncludedDestination</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: java; gutter: false; theme: Default"
style="font-size:12px;"><networkConnector uri="static:(tcp://host)">
+ <dynamicallyIncludedDestinations>
+ <topic physicalName="include.test.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: java; gutter: false; theme: Default"
style="font-size:12px;"><compositeTopic name="include.test.bar"
forwardOnly="false">
+ <forwardTo>
+ <queue physicalName="include.test.bar.forward" />
+ </forwardTo>
+</compositeTopic ></pre>
+</div></div><p><br clear="none">In this example, let's consider a single
consumer on the remote broker on the queue include.test.bar.forward.  If a
message is sent directly to the remote broker on the
topic <code>include.test.bar, it</code> will be forwarded to the
queue <code>include.test.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.test.bar.forward</code> would not be
detected as part of
the <code>dynamicallyIncludedDestinations</code> list so messages
would not be forwarded to the remote broker unless there was a consumer on the
original topic as well, in this case include.test.bar.  This can be fixed
by configuring the broker to listen for Virtual Destination Subscriptions.
 </p><p>First, we need t
o configure the broker to send advisory messages when consumers come online
onto a destination that matches a Virtual Destination.  In this case, a
match is determined by the use of a Destination Filter will determines if a a
destination forwards to another destination.  The configuration on the
remote broker should be updated to set the property
<code>useVirtualDestSubs</code> to true to enable this.</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 class="codeContent panelContent pdl">
+<pre class="brush: java; gutter: false; theme: Default"
style="font-size:12px;"><?xml version="1.0" encoding="UTF-8"?>
+
+<beans xmlns="http://activemq.org/config/1.0">
+
+ <broker name="broker1" useVirtualDestSubs="true">
+ .....
+ </broker>
+
+</beans>
+</pre>
+</div></div><p><br clear="none">Second, we need to configure the network
connector to listen for the new advisory messages:</p><p> </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: java; gutter: false; theme: Default"
style="font-size:12px;"><networkConnector uri="static:(tcp://host)"
useVirtualDestSubs="true">
+ <dynamicallyIncludedDestinations>
+ <topic physicalName="include.test.bar"/>
+ </dynamicallyIncludedDestinations>
+</networkConnector></pre>
+</div></div><p><br clear="none">Now, if a consumer comes online for the
queue <code>include.test.bar.forward</code> on the remote broker, the
local broker will know to forward messages that are sent to the
topic <code>include.test.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: java; gutter: false; theme: Default"
style="font-size:12px;"><compositeTopic name="include.test.bar"
forwardOnly="false">
+ <forwardTo>
+ <queue physicalName="include.test.bar.forward" />
+ </forwardTo>
+</compositeTopic ></pre>
+</div></div><p><br clear="none">There is a composite Topic configured on the
remote broker and the local broker is networked to it.  Even though we've
enabled useVirtualDestSubs, messages wouldn't be forwarded to the remote broker
unless a consumer comes online to the forwarded queue.  This would cause
messages to be dropped since they are sent to a topic.  Sometimes it is
desirable to have these messages forwarded based on the existence of the
virtual destination.  This only applies in the Queue case. For topics,
messages should only be forwarded if there is a consumer or durable
subscription.</p><p> </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: java; gutter: false; theme: Default"
style="font-size:12px;"><?xml version="1.0" encoding="UTF-8"?>
+
+<beans xmlns="http://activemq.org/config/1.0">
+
+ <broker name="broker1" useVirtualDestSubs="true"
useVirtualDestSubsOnCreation="true">
+ .....
+ </broker>
+
+</beans>
+</pre>
+</div></div><p><br clear="none">With this configuration, when the
Queue include.test.bar.forward 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 CompositeTopic and Queue existing.</p><h4
id="NetworksofBrokers-VirtualDestinationconsumersandVirtualTopics">Virtual
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 will now
cause demand and messages will be sent across a network.</p><p> </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: java; gutter: false; theme: Default"
style="font-size:12px;"><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: java; gutter: false; theme: Default"
style="font-size:12px;"><?xml version="1.0" encoding="UTF-8"?>
+
+<beans xmlns="http://activemq.org/config/1.0">
+
+ <broker name="broker1" useVirtualDestSubs="true" >
+ .....
+ </broker>
+
+</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: xml; gutter: false; theme: Default"
style="font-size:12px;"><networkConnectors>
<networkConnector uri="static:(tcp://localhost:61617)"
name="bridge"
![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}