activemq-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From build...@apache.org
Subject svn commit: r972011 - in /websites/production/activemq/content: cache/main.pageCache networks-of-brokers.html
Date Tue, 10 Nov 2015 18:21:31 GMT
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&amp;consumer -TTL)</p></td></tr><tr><td
colspan="1" rowspan="1" class="confluenceTd"><p>messageTTL</p></td><td
colspan="1" rowspan="1" class="confluenceTd"><p>1</p></td><td colspan="1"
rowspan="1" class="confluenceTd"><p>(version 5.9) the number of brokers in the network
that messages can pass through</p></td></tr><tr><td colspan="1"
rowspan="1" class="confluenceTd"><p>consumerTTL</p></td><td colspan="1"
rowspan="1" class="confluenceTd"><p>1</p></td><td colspan="1" rowspan="1"
class="confluenceTd"><p>(version 5.9) the number of brokers in the network that subscriptions
can pass through (keep to 1 in a mesh)</p></td></tr><tr><td colspan="1"
rowspan="1" class="confluenceTd"><p>conduitSubscriptions</p></td><td
colspan="1" rowspan="1" class="confluenceTd"><p>true</
 p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>multiple
consumers subscribing to the same destination are treated as one consumer by the network</p></td></tr><tr><td
colspan="1" rowspan="1" class="confluenceTd"><p>excludedDestinations</p></td><td
colspan="1" rowspan="1" class="confluenceTd"><p>empty</p></td><td
colspan="1" rowspan="1" class="confluenceTd"><p>destinations matching this list won't
be forwarded across the network</p></td></tr><tr><td colspan="1"
rowspan="1" class="confluenceTd"><p>dynamicallyIncludedDestinations</p></td><td
colspan="1" rowspan="1" class="confluenceTd"><p>empty</p></td><td
colspan="1" rowspan="1" class="confluenceTd"><p>destinations that match this list
<strong>will</strong> be forwarded across the network <strong>n.b.</strong>
an empty list means all destinations not in the exluded list will be forwarded</p></td></tr><tr><td
colspan="1" rowspan="1" class="confluenceTd"><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 &gt; 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&amp;consumer -TTL)</p></td></tr><tr><td
colspan="1" rowspan="1" class="confluenceTd"><p>messageTTL</p></td><td
colspan="1" rowspan="1" class="confluenceTd"><p>1</p></td><td colspan="1"
rowspan="1" class="confluenceTd"><p>(version 5.9) the number of brokers in the network
that messages can pass through</p></td></tr><tr><td colspan="1"
rowspan="1" class="confluenceTd"><p>consumerTTL</p></td><td colspan="1"
rowspan="1" class="confluenceTd"><p>1</p></td><td colspan="1" rowspan="1"
class="confluenceTd"><p>(version 5.9) the number of brokers in the network that subscriptions
can pass through (keep to 1 in a mesh)</p></td></tr><tr><td colspan="1"
rowspan="1" class="confluenceTd"><p>conduitSubscriptions</p></td><td
colspan="1" rowspan="1" class="confluenceTd"><p>true</
 p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>multiple
consumers subscribing to the same destination are treated as one consumer by the network</p></td></tr><tr><td
colspan="1" rowspan="1" class="confluenceTd"><p>excludedDestinations</p></td><td
colspan="1" rowspan="1" class="confluenceTd"><p>empty</p></td><td
colspan="1" rowspan="1" class="confluenceTd"><p>destinations matching this list won't
be forwarded across the network</p></td></tr><tr><td colspan="1"
rowspan="1" class="confluenceTd"><p>dynamicallyIncludedDestinations</p></td><td
colspan="1" rowspan="1" class="confluenceTd"><p>empty</p></td><td
colspan="1" rowspan="1" class="confluenceTd"><p>destinations that match this list
<strong>will</strong> be forwarded across the network <strong>n.b.</strong>
an empty list means all destinations not in the exluded list will be forwarded</p></td></tr><tr><td
colspan="1" rowspan="1" class="confluenceTd">useVirtualDestSubs</td><td colspan="1"
rowspan="1" class="confluenceTd">
 false</td><td colspan="1" rowspan="1" class="confluenceTd">if true, the network
connection will listen to advisory messages for virtual destination consumers</td></tr><tr><td
colspan="1" rowspan="1" class="confluenceTd"><p>staticallyIncludedDestinations</p></td><td
colspan="1" rowspan="1" class="confluenceTd"><p>empty</p></td><td
colspan="1" rowspan="1" class="confluenceTd"><p>destinations that match will always
be passed across the network - even if no consumers have ever registered an interest</p></td></tr><tr><td
colspan="1" rowspan="1" class="confluenceTd"><p>duplex</p></td><td
colspan="1" rowspan="1" class="confluenceTd"><p>false</p></td><td
colspan="1" rowspan="1" class="confluenceTd"><p>if true, a network connection will
be used to both produce <strong><em>AND</em></strong> Consume messages.
This is useful for hub and spoke scenarios when the hub is behind a firewall etc.</p></td></tr><tr><td
colspan="1" rowspan="1" class="confluenceTd"><p>prefetchSize</p></td><td
colspan="1"
  rowspan="1" class="confluenceTd"><p>1000</p></td><td colspan="1"
rowspan="1" class="confluenceTd"><p>Sets the <a shape="rect" href="what-is-the-prefetch-limit-for.html">prefetch
size</a> on the network connector's consumer. It must be &gt; 0 because network
consumers do not poll for messages</p></td></tr><tr><td colspan="1"
rowspan="1" class="confluenceTd"><p>suppressDuplicateQueueSubscriptions</p></td><td
colspan="1" rowspan="1" class="confluenceTd"><p>false</p></td><td
colspan="1" rowspan="1" class="confluenceTd"><p>(from 5.3) if true, duplicate subscriptions
in the network that arise from network intermediaries will be suppressed. For example, given
brokers A,B and C, networked via multicast discovery. A consumer on A will give rise to a
networked consumer on B and C. In addition, C will network to B (based on the network consumer
from A) and B will network to C. When true, the network bridges between C and B (being duplicates
of their existing network subscriptions to A) will b
 e suppressed. Reducing the routing choices in this way provides determinism when producers
or consumers migrate across the network as the potential for dead routes (stuck messages)
are eliminated. networkTTL needs to match or exceed the broker count to require this intervention.</p></td></tr><tr><td
colspan="1" rowspan="1" class="confluenceTd"><p>bridgeTempDestinations</p></td><td
colspan="1" rowspan="1" class="confluenceTd"><p>true</p></td><td colspan="1"
rowspan="1" class="confluenceTd"><p>Whether to broadcast advisory messages for created
temp destinations in the network of brokers or not. Temp destinations are typically created
for request-reply messages. Broadcasting the information about temp destinations is turned
on by default so that consumers of a request-reply message can be connected to another broker
in the network and still send back the reply on the temporary destination specified in the
JMSReplyTo header. In an application scenario where most/all messages use request
 -reply pattern, this will generate additional traffic on the broker network as every message
typically sets a unique JMSReplyTo address (which causes a new temp destination to be created
and broadcasted via an advisory message in the network of brokers). <br clear="none">
When disabling this feature such network traffic can be reduced but then producer and consumers
of a request-reply message need to be connected to the same broker. Remote consumers (i.e.
connected via another broker in your network) won't be able to send the reply message but
instead raise a "temp destination does not exist" exception.</p></td></tr><tr><td
colspan="1" rowspan="1" class="confluenceTd"><p>alwaysSyncSend</p></td><td
colspan="1" rowspan="1" class="confluenceTd"><p>false</p></td><td
colspan="1" rowspan="1" class="confluenceTd"><p>(version 5.6) When true, non persistent
messages are sent to the remote broker using request/reply in place of a oneway. This setting
treats both persistent and non-persistent 
 messages the same.</p></td></tr><tr><td colspan="1" rowspan="1"
class="confluenceTd"><p>staticBridge</p></td><td colspan="1" rowspan="1"
class="confluenceTd"><p>false</p></td><td colspan="1" rowspan="1"
class="confluenceTd"><p>(version 5.6) If set to true, broker will not dynamically
respond to new consumers. It will only use <code>staticallyIncludedDestinations</code>
to create demand subscriptions</p></td></tr></tbody></table></div><h4
id="NetworksofBrokers-Reliability">Reliability</h4><p>Networks of brokers do
reliable store and forward of messages. If the source is durable, persistent messages on a
queue or a durable topic subscription, a network will retain the durability guarantee. <br
clear="none"> However networks cannot add durability when the source is non durable. Non
durable topic subscriptions and temporary destinations (both queues and topics) are non durable
by definition. When non durable<br clear="none"> sources are networked, in the event
of a failure, inflight mes
 sages can be lost.</p><h4 id="NetworksofBrokers-Ordering">Ordering</h4><p>Total
message ordering is not preserved with networks of brokers. Total ordering <a shape="rect"
href="how-do-i-preserve-order-of-messages.html">works with a single consumer</a>
but a networkBridge introduces a second consumer. In addition, network bridge consumers forward
messages via producer.send(..), so they go from the head of the queue on the forwarding broker
to the tail of the queue on the target. If single consumer moves between networked brokers,
total order may be preserved if all messages always follow the consumer but this can be difficult
to guarantee with large message backlogs.</p><h4 id="NetworksofBrokers-WhentouseandnotuseConduitsubscriptions">When
to use and not use Conduit subscriptions</h4><p>ActiveMQ relies on information
about active consumers (subscriptions) to pass messages around the network. A broker interprets
a subscription from a remote (networked) broker in the same way as it wou
 ld a subscription from a local client connection and routes a copy of any relevant message
to each subscription. With Topic subscriptions and with more than one remote subscription,
a remote broker would interpret each message copy as valid, so when it in turns routes the
messages to its own local connections, duplicates would occur. Hence default conduit behavior
consolidates all matching subscription information to prevent duplicates flowing around the
network. With this default behaviour, N subscriptions on a remote broker look like a single
subscription to the networked broker.</p><p>However - duplicate subscriptions
is a useful feature to exploit if you are only using Queues. As the load balancing algorithm
will attempt to share message load evenly, consumers across a network will equally share the
message load only if the flag 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;">&lt;networkConnectors&gt;
         &lt;networkConnector name="SYSTEM1" duplex="true" uri="static:(tcp://10.x.x.x:61616)"&gt;
                 &lt;dynamicallyIncludedDestinations&gt;
@@ -176,7 +176,69 @@
       		&lt;queue physicalName="always.include.queue"/&gt;
         &lt;/staticallyIncludedDestinations&gt;
 &lt;/networkConnector&gt;</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. &#160;However, let's consider some cases of how dynamic flow
occurs when&#160;<a shape="rect" href="virtual-destinations.html">Virtual Destinations</a>&#160;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. &#160;The local broker contains the network connector
configured with a&#160;<code>dy
 namicallyIncludedDestination</code>&#160;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;">&lt;networkConnector
uri="static:(tcp://host)"&gt;
+  &lt;dynamicallyIncludedDestinations&gt;
+    &lt;topic physicalName="include.test.bar"/&gt;
+  &lt;/dynamicallyIncludedDestinations&gt;
+&lt;/networkConnector&gt;</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;">&lt;compositeTopic
name="include.test.bar" forwardOnly="false"&gt;
+    &lt;forwardTo&gt;
+        &lt;queue physicalName="include.test.bar.forward" /&gt;
+    &lt;/forwardTo&gt;
+&lt;/compositeTopic &gt;</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. &#160;If a
message is sent directly to the remote broker on the topic&#160;<code>include.test.bar,
it</code>&#160;will be forwarded to the queue&#160;<code>include.test.bar.forward&#160;</code>and
the consumer will receive it. &#160;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&#160;<code>queue&#160;include.test.bar.forward</code>&#160;would
not be detected as part of the&#160;<code>dynamicallyIncludedDestinations</code>&#160;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. &#160;This can be fixed by configuring
the broker to listen for Virtual Destination Subscriptions. &#160;</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. &#160;In this case, a match is determined by the use
of a Destination Filter will determines if a a destination forwards to another destination.
&#160;The configuration on the remote broker should be updated to set the property <code>useVirtualDestSubs</code>
to true to enable this.</p><p>&#160;</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;">&lt;?xml
version="1.0" encoding="UTF-8"?&gt;
+
+&lt;beans xmlns="http://activemq.org/config/1.0"&gt;
+
+  &lt;broker name="broker1" useVirtualDestSubs="true"&gt;  
+     .....
+  &lt;/broker&gt;
+
+&lt;/beans&gt;
+</pre>
+</div></div><p><br clear="none">Second, we need to configure the
network connector to listen for the new advisory messages:</p><p>&#160;</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;">&lt;networkConnector
uri="static:(tcp://host)" useVirtualDestSubs="true"&gt;
+  &lt;dynamicallyIncludedDestinations&gt;
+    &lt;topic physicalName="include.test.bar"/&gt;
+  &lt;/dynamicallyIncludedDestinations&gt;
+&lt;/networkConnector&gt;</pre>
+</div></div><p><br clear="none">Now, if a consumer comes online for
the queue&#160;<code>include.test.bar.forward</code>&#160;on the remote
broker, the local broker will know to forward messages that are sent to the topic&#160;<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">&#160;</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;">&lt;compositeTopic
name="include.test.bar" forwardOnly="false"&gt;
+    &lt;forwardTo&gt;
+        &lt;queue physicalName="include.test.bar.forward" /&gt;
+    &lt;/forwardTo&gt;
+&lt;/compositeTopic &gt;</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. &#160;Even though we've
enabled useVirtualDestSubs, messages wouldn't be forwarded to the remote broker unless a consumer
comes online to the forwarded queue. &#160;This would cause messages to be dropped since
they are sent to a topic. &#160;Sometimes it is desirable to have these messages forwarded
based on the existence of the virtual destination. &#160;This only applies in the Queue
case. For topics, messages should only be forwarded if there is a consumer or durable subscription.</p><p>&#160;</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;">&lt;?xml
version="1.0" encoding="UTF-8"?&gt;
+
+&lt;beans xmlns="http://activemq.org/config/1.0"&gt;
+
+  &lt;broker name="broker1" useVirtualDestSubs="true" useVirtualDestSubsOnCreation="true"&gt;
 
+     .....
+  &lt;/broker&gt;
+
+&lt;/beans&gt;
+</pre>
+</div></div><p><br clear="none">With this configuration, when the
Queue&#160;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&#160;</h4><p>The above examples show
how to configure a Composite destination but a Virtual Topic will also work. &#160;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>&#160;</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;">&lt;networkConnector
uri="static:(tcp://host)"&gt;
+  &lt;dynamicallyIncludedDestinations&gt;
+    &lt;topic physicalName="VirtualTopic.&gt;"/&gt;
+  &lt;/dynamicallyIncludedDestinations&gt;
+&lt;/networkConnector&gt;</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;">&lt;?xml
version="1.0" encoding="UTF-8"?&gt;
+
+&lt;beans xmlns="http://activemq.org/config/1.0"&gt;
+
+  &lt;broker name="broker1" useVirtualDestSubs="true" &gt;  
+     .....
+  &lt;/broker&gt;
+
+&lt;/beans&gt;</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;">&lt;networkConnectors&gt;
       &lt;networkConnector uri="static:(tcp://localhost:61617)"
          name="bridge"



Mime
View raw message