activemq-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From build...@apache.org
Subject svn commit: r975063 - in /websites/production/activemq/content: cache/main.pageCache networks-of-brokers.html
Date Wed, 09 Dec 2015 12:22:35 GMT
Author: buildbot
Date: Wed Dec  9 12:22:35 2015
New Revision: 975063

Log:
Production update by buildbot for activemq

Modified:
    websites/production/activemq/content/cache/main.pageCache
    websites/production/activemq/content/networks-of-brokers.html

Modified: websites/production/activemq/content/cache/main.pageCache
==============================================================================
Binary files - no diff available.

Modified: websites/production/activemq/content/networks-of-brokers.html
==============================================================================
--- websites/production/activemq/content/networks-of-brokers.html (original)
+++ websites/production/activemq/content/networks-of-brokers.html Wed Dec  9 12:22:35 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">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">
+</div></div><p>The URIs are listed in order for: MASTER,SLAVE1,SLAVE2...SLAVE<img class="emoticon emoticon-thumbs-down" src="https://cwiki.apache.org/confluence/s/en_GB/5982/f2b47fb3d636c8bc9fd0b11c0ec6d0ae18646be7.1/_/images/icons/emoticons/thumbs_down.png" data-emoticon-name="thumbs-down" alt="(thumbs down)"></p><p>The same configuration options for <code>static:</code> are available for <code>masterslave:</code></p><h2 id="NetworksofBrokers-NetworkConnectorProperties">NetworkConnector Properties</h2><div class="table-wrap"><table class="confluenceTable"><tbody><tr><th colspan="1" rowspan="1" class="confluenceTh"><p>property</p></th><th colspan="1" rowspan="1" class="confluenceTh"><p>default</p></th><th colspan="1" rowspan="1" class="confluenceTh"><p>description</p></th></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><p>name</p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>bridge</p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>name of the network -
  for more than one network connector between the same two brokers - use different names</p></td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><p>dynamicOnly</p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>false</p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>if true, only activate a networked durable subscription when a corresponding durable subscription reactivates, by default they are activated on startup.</p></td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><p>decreaseNetworkConsumerPriority</p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>false</p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>if true, starting at priority -5, decrease the priority for dispatching to a network Queue consumer the further away it is (in network hops) from the producer. When false all network consumers use same default priority(0) as local consumers</p></td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><p>networkTTL</
 p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>1</p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>the number of brokers in the network that messages and subscriptions can pass through (sets both message&amp;consumer -TTL)</p></td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><p>messageTTL</p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>1</p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>(version 5.9) the number of brokers in the network that messages can pass through</p></td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><p>consumerTTL</p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>1</p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>(version 5.9) the number of brokers in the network that subscriptions can pass through (keep to 1 in a mesh)</p></td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><p>conduitSubscriptions</p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>true</
 p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>multiple consumers subscribing to the same destination are treated as one consumer by the network</p></td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><p>excludedDestinations</p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>empty</p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>destinations matching this list won't be forwarded across the network</p></td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><p>dynamicallyIncludedDestinations</p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>empty</p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>destinations that match this list <strong>will</strong> be forwarded across the network <strong>n.b.</strong> an empty list means all destinations not in the exluded list will be forwarded</p></td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd">useVirtualDestSubs</td><td colspan="1" rowspan="1" class="confluenceTd">
 false</td><td colspan="1" rowspan="1" class="confluenceTd">if true, the network connection will listen to advisory messages for virtual destination consumers</td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><p>staticallyIncludedDestinations</p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>empty</p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>destinations that match will always be passed across the network - even if no consumers have ever registered an interest</p></td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><p>duplex</p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>false</p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>if true, a network connection will be used to both produce <strong><em>AND</em></strong> Consume messages. This is useful for hub and spoke scenarios when the hub is behind a firewall etc.</p></td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><p>prefetchSize</p></td><td colspan="1"
  rowspan="1" class="confluenceTd"><p>1000</p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>Sets the <a shape="rect" href="what-is-the-prefetch-limit-for.html">prefetch size</a> on the network connector's consumer. It must be &gt; 0 because network consumers do not poll for messages</p></td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><p>suppressDuplicateQueueSubscriptions</p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>false</p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>(from 5.3) if true, duplicate subscriptions in the network that arise from network intermediaries will be suppressed. For example, given brokers A,B and C, networked via multicast discovery. A consumer on A will give rise to a networked consumer on B and C. In addition, C will network to B (based on the network consumer from A) and B will network to C. When true, the network bridges between C and B (being duplicates of their existing network subscriptions to A) will b
 e suppressed. Reducing the routing choices in this way provides determinism when producers or consumers migrate across the network as the potential for dead routes (stuck messages) are eliminated. networkTTL needs to match or exceed the broker count to require this intervention.</p></td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><p>bridgeTempDestinations</p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>true</p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>Whether to broadcast advisory messages for created temp destinations in the network of brokers or not. Temp destinations are typically created for request-reply messages. Broadcasting the information about temp destinations is turned on by default so that consumers of a request-reply message can be connected to another broker in the network and still send back the reply on the temporary destination specified in the JMSReplyTo header. In an application scenario where most/all messages use request
 -reply pattern, this will generate additional traffic on the broker network as every message typically sets a unique JMSReplyTo address (which causes a new temp destination to be created and broadcasted via an advisory message in the network of brokers). <br clear="none"> When disabling this feature such network traffic can be reduced but then producer and consumers of a request-reply message need to be connected to the same broker. Remote consumers (i.e. connected via another broker in your network) won't be able to send the reply message but instead raise a "temp destination does not exist" exception.</p></td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><p>alwaysSyncSend</p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>false</p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>(version 5.6) When true, non persistent messages are sent to the remote broker using request/reply in place of a oneway. This setting treats both persistent and non-persistent 
 messages the same.</p></td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><p>staticBridge</p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>false</p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>(version 5.6) If set to true, broker will not dynamically respond to new consumers. It will only use <code>staticallyIncludedDestinations</code> to create demand subscriptions</p></td></tr></tbody></table></div><h4 id="NetworksofBrokers-Reliability">Reliability</h4><p>Networks of brokers do reliable store and forward of messages. If the source is durable, persistent messages on a queue or a durable topic subscription, a network will retain the durability guarantee. <br clear="none"> However networks cannot add durability when the source is non durable. Non durable topic subscriptions and temporary destinations (both queues and topics) are non durable by definition. When non durable<br clear="none"> sources are networked, in the event of a failure, inflight mes
 sages can be lost.</p><h4 id="NetworksofBrokers-Ordering">Ordering</h4><p>Total message ordering is not preserved with networks of brokers. Total ordering <a shape="rect" href="how-do-i-preserve-order-of-messages.html">works with a single consumer</a> but a networkBridge introduces a second consumer. In addition, network bridge consumers forward messages via producer.send(..), so they go from the head of the queue on the forwarding broker to the tail of the queue on the target. If single consumer moves between networked brokers, total order may be preserved if all messages always follow the consumer but this can be difficult to guarantee with large message backlogs.</p><h4 id="NetworksofBrokers-WhentouseandnotuseConduitsubscriptions">When to use and not use Conduit subscriptions</h4><p>ActiveMQ relies on information about active consumers (subscriptions) to pass messages around the network. A broker interprets a subscription from a remote (networked) broker in the same way as it wou
 ld a subscription from a local client connection and routes a copy of any relevant message to each subscription. With Topic subscriptions and with more than one remote subscription, a remote broker would interpret each message copy as valid, so when it in turns routes the messages to its own local connections, duplicates would occur. Hence default conduit behavior consolidates all matching subscription information to prevent duplicates flowing around the network. With this default behaviour, N subscriptions on a remote broker look like a single subscription to the networked broker.</p><p>However - duplicate subscriptions is a useful feature to exploit if you are only using Queues. As the load balancing algorithm will attempt to share message load evenly, consumers across a network will equally share the message load only if the flag <code>conduitSubscriptions=false</code>. Here's an example. Suppose you have two brokers, A and B, that are connected to one another via a forwarding br
 idge. Connected to broker A, you have a consumer that subscribes to a queue called <code>Q.TEST</code>. Connected to broker B, you have two consumers that also subscribe to <code>Q.TEST</code>. All consumers have equal priority. Then you start a producer on broker A that writes 30 messages to <code>Q.TEST</code>. By default, (<code>conduitSubscriptions=true</code>), 15 messages will be sent to the consumer on broker A and the resulting 15 messages will be sent to the two consumers on broker B. The message load has not been equally spread across all three consumers because, by default, broker A views the two subscriptions on broker B as one. If you had set <code>conduitSubscriptions</code> to&#160;<code>false</code>, then each of the three consumers would have been given 10 messages.</p><h4 id="NetworksofBrokers-Duplexnetworkconnectors">Duplex network connectors</h4><p>By default a network bridge forwards messages on demand in one direction over a single connection. When <code>duplex
 =true</code>, the same connection is used for a network bridge in the opposite directions, resulting in a bi-directional bridge. The network bridge configuration is propagated to the other broker so the duplex bridge is an exact replica or the original.</p><p><br clear="none"> Given two brokers, broker A and broker B, a duplex bridge on A to B is the same as a default bridge on A to B and a default bridge on B to A.</p><p><br clear="none"> Note, if you want to configure more than one duplex network bridge between two brokers, to increase throughput or to partition topics and queues, you must provide unique names for each:</p><div class="code panel pdl" style="border-width: 1px;"><div class="codeContent panelContent pdl">
 <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;
@@ -150,78 +150,78 @@
                 &lt;/dynamicallyIncludedDestinations&gt;
         &lt;/networkConnector&gt;
   &lt;/networkConnectors&gt;</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 advisorySupport broker property is disabled. A fully statically configured network is the only option if advisorySupport 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.&gt;</code> (let's ignore temporary destination for the moment). In this way, when consumer connects (or disconnects) to the remote broker, the lo
 cal 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">
+</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.&gt;</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: xml; gutter: false; theme: Default" style="font-size:12px;">&lt;networkConnector uri="static:(tcp://host)"&gt;
   &lt;dynamicallyIncludedDestinations&gt;
     &lt;queue physicalName="include.test.foo"/&gt;
     &lt;topic physicalName="include.test.bar"/&gt;
   &lt;/dynamicallyIncludedDestinations&gt;
 &lt;/networkConnector&gt;</pre>
-</div></div><p>In earlier versions of ActiveMQ, 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>So what's to be done in older versions of the broker? Luckily, we can achieve the same thing with a bit more complicated configuration. The actual advisory filter that controls in which consumers we are interested is defined with the <code>destinationFilter</code> co
 nnector property. It's default value is <code>&gt;</code>, 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">
+</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 "&gt;", 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: xml; gutter: false; theme: Default" style="font-size:12px;">&lt;networkConnector uri="static:(tcp://host)" destinationFilter="Queue.include.test.foo,ActiveMQ.Advisory.Consumer.Topic.include.test.bar"&gt;
   &lt;dynamicallyIncludedDestinations&gt;
     &lt;queue physicalName="include.test.foo"/&gt;
     &lt;topic physicalName="include.test.bar"/&gt;
   &lt;/dynamicallyIncludedDestinations&gt;
 &lt;/networkConnector&gt;</pre>
-</div></div><p>Note that first destination doesn't 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 doesn't 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">
+</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: xml; gutter: false; theme: Default" style="font-size:12px;">&lt;networkConnector uri="static:(tcp://host)" staticBridge="true"&gt;
         &lt;staticallyIncludedDestinations&gt;
       		&lt;queue physicalName="always.include.queue"/&gt;
         &lt;/staticallyIncludedDestinations&gt;
 &lt;/networkConnector&gt;</pre>
-</div></div><p>The <code>staticBridge</code> parameter is available since version 5.6 and it means that broker will not subscribe to any advisory topic on the remote broker, meaning it is not interested in 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's 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">
+</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: xml; gutter: false; theme: Default" style="font-size:12px;">&lt;networkConnector uri="static:(tcp://host)" destinationFilter="NO_DESTINATION"&gt;
         &lt;staticallyIncludedDestinations&gt;
       		&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-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. &#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 netwo
 rked together. &#160;The local broker contains the network connector configured with a&#160;<code>dynamicallyIncludedDestination</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">
+</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. &#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 netwo
 rked together. &#160;The Local Broker contains the network connector configured with a&#160;<code>dynamicallyIncludedDestination</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: xml; 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;topic physicalName="include.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: xml; gutter: false; theme: Default" style="font-size:12px;">&lt;compositeTopic name="include.test.bar" forwardOnly="false"&gt;
+<pre class="brush: xml; gutter: false; theme: Default" style="font-size:12px;">&lt;compositeTopic name="include.bar" forwardOnly="false"&gt;
     &lt;forwardTo&gt;
-        &lt;queue physicalName="include.test.bar.forward" /&gt;
+        &lt;queue physicalName="include.bar.forward" /&gt;
     &lt;/forwardTo&gt;
 &lt;/compositeTopic &gt;</pre>
-</div></div><p>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 to configure the b
 roker 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><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">
+</div></div><p>In this example, let's consider a single consumer on the Remote Broker on the queue <code>include.bar.forward</code>. &#160;If a message is sent directly to the Remote Broker on the topic&#160;<code>include.bar</code>, it&#160;will be forwarded to the queue&#160;<code>include.bar.forward</code>&#160;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.bar.forward</code>&#160;would not be detected as part of the&#160;<code>dynamicallyIncludedDestinations</code>&#160;list in the Local Broker.&#160; 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>). &#160;This can be fixed by configuring the Local Broker to listen for Virtual Destination Subscriptions. &#160;</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. &#160;In this case, internally a match is determined through the use of a Destination Filter that determines whether one destination forwards to another destination.&#160; 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;">&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 name="remoteBroker" 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><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">
+</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;">&lt;networkConnector uri="static:(tcp://host)" useVirtualDestSubs="true"&gt;
   &lt;dynamicallyIncludedDestinations&gt;
-    &lt;topic physicalName="include.test.bar"/&gt;
+    &lt;topic physicalName="include.bar"/&gt;
   &lt;/dynamicallyIncludedDestinations&gt;
 &lt;/networkConnector&gt;</pre>
-</div></div><p>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: xml; gutter: false; theme: Default" style="font-size:12px;">&lt;compositeTopic name="include.test.bar" forwardOnly="false"&gt;
+</div></div><p>Now, if a consumer comes subscribes to the queue&#160;<code>include.bar.forward</code>&#160;on the Remote Broker, the Local Broker will forward messages that are sent to the topic&#160;<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">&#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: xml; gutter: false; theme: Default" style="font-size:12px;">&lt;compositeTopic name="include.bar" forwardOnly="false"&gt;
     &lt;forwardTo&gt;
-        &lt;queue physicalName="include.test.bar.forward" /&gt;
+        &lt;queue physicalName="include.bar.forward" /&gt;
     &lt;/forwardTo&gt;
 &lt;/compositeTopic &gt;</pre>
-</div></div><p>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><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">
+</div></div><p>There is a Composite Topic configured on the Remote Broker, and the Local Broker is networked to it. &#160;</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.&#160; Without a consumer, messages would be dropped as they are sent to a topic on the Local Broker (<code>include.bar</code>).&#160; 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>&#160;</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>&#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 cl
 ass="codeContent panelContent pdl">
 <pre class="brush: xml; 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 name="remoteBroker" useVirtualDestSubs="true" useVirtualDestSubsOnCreation="true"&gt;  
      .....
   &lt;/broker&gt;
 
 &lt;/beans&gt;</pre>
-</div></div><p>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">
+</div></div><p>With this configuration, when the queue&#160;<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&#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 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;">&lt;networkConnector uri="static:(tcp://host)"&gt;
   &lt;dynamicallyIncludedDestinations&gt;
     &lt;topic physicalName="VirtualTopic.&gt;"/&gt;
@@ -232,7 +232,7 @@
 
 &lt;beans xmlns="http://activemq.org/config/1.0"&gt;
 
-  &lt;broker name="broker1" useVirtualDestSubs="true" &gt;  
+  &lt;broker name="remoteBroker" useVirtualDestSubs="true" &gt;  
      .....
   &lt;/broker&gt;
 
@@ -258,7 +258,7 @@
       &lt;/networkConnector&gt;
     &lt;/networkConnectors&gt;
 </pre>
-</div></div><p>It is possible to have more than one network connector between two brokers. Each network connector uses one underlying transport connection, so you may wish to do this to increase throughput, or have a more flexible configuration.<br clear="none"> For example, if using distributed queues, you may wish to have equivalent weighting to queue receivers across the network, but only when the receivers are active - e.g.</p><div class="code panel pdl" style="border-width: 1px;"><div class="codeContent panelContent pdl">
+</div></div><p>It is possible to have more than one network connector between two brokers. Each network connector uses one underlying transport connection, so you may wish to do this to increase throughput, or have a more flexible configuration.</p><p><br clear="none"> For example, if using distributed queues, you may wish to have equivalent weighting to queue receivers across the network, but only when the receivers are active - e.g.</p><div class="code panel pdl" style="border-width: 1px;"><div class="codeContent panelContent pdl">
 <pre class="brush: xml; gutter: false; theme: Default" style="font-size:12px;">&lt;networkConnectors&gt;
       &lt;networkConnector uri="static:(tcp://localhost:61617)"
          name="queues_only"
@@ -270,7 +270,7 @@
       &lt;/networkConnector&gt;
     &lt;/networkConnectors&gt;
 </pre>
-</div></div><p><strong>N.B.</strong> You can only use <a shape="rect" href="wildcards.html">wildcards</a> in the excludedDestinations and dynamicallyIncludedDestinations 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 ActiceMQ uses the network name and broker name to build a unique but repeatable durable subscriber name for the network.</p><h3 id="NetworksofBrokers-StuckMessages(version5.6)">Stuck Messages (version 5.6)</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.<br clear="none"> There is a destination policy that allows this behavior for queues by configuring a conditionalNetworkBridgeFilterFactory with replayWhenNoConsumers=true. The conditionalNetworkBridgeFilterFactory provides an optional replayDelay based on the broker-in time.</p><div class="code panel pdl" style="border-width: 1px;"><div class="codeContent panelContent pdl">
+</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(version5.6)">Stuck Messages (version 5.6)</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 c
 hoose a broker using the failover 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.<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 <code>replayDelay</code> based on the broker-in time.</p><div class="code panel pdl" style="border-width: 1px;"><div class="codeCont
 ent panelContent pdl">
 <pre class="brush: xml; gutter: false; theme: Default" style="font-size:12px;">    &lt;destinationPolicy&gt;
       &lt;policyMap&gt;
         &lt;policyEntries&gt;
@@ -282,7 +282,7 @@
         &lt;/policyEntries&gt;
       &lt;/policyMap&gt;
     &lt;/destinationPolicy&gt;</pre>
-</div></div><p><strong>N.B.:</strong> When using replayWhenNoConsumers=true for versions &lt; 5.9, it is necessary to also disable the cursors duplicate detection using <strong>enableAudit=false</strong> as the cursor could mark the replayed messages as duplicates (depending on the time window between playing and replaying these messages over the network bridge). The problem is fully explained in this <a shape="rect" class="external-link" href="http://tmielke.blogspot.de/2012/03/i-have-messages-on-queue-but-they-dont.html" rel="nofollow">blog post</a>.</p><h4 id="NetworksofBrokers-Throttlinganetworkconsumer">Throttling a network consumer</h4><p>The conditionalNetworkBridgeFilterFactory factory allows a rate limit to be specified for a destination, such that network consumer can be throttled. Prefetch for a network consumer is largely negated by the fact that a network consumer relays a message typically acks very quickly so even with a low prefetch and decreased priority a network c
 onsumer can starve a modestly quick local consumer. Throttling provides a remedy for this.</p></div>
+</div></div><p><strong>N.B.:</strong> When using <code>replayWhenNoConsumers=true</code> for versions &lt; 5.9, it is necessary to also disable the cursors duplicate detection using <code><strong>enableAudit=false</strong></code> as the cursor could mark the replayed messages as duplicates (depending on the time window between playing and replaying these messages over the network bridge). The problem is fully explained in this <a shape="rect" class="external-link" href="http://tmielke.blogspot.de/2012/03/i-have-messages-on-queue-but-they-dont.html" rel="nofollow">blog post</a>.</p><h4 id="NetworksofBrokers-Throttlinganetworkconsumer">Throttling a network consumer</h4><p>The <code>conditionalNetworkBridgeFilterFactory</code> factory allows a rate limit to be specified for a destination, such that network consumer can be throttled. Prefetch for a network consumer is largely negated by the fact that a network consumer relays a message typically acks very quickly so even with a low pref
 etch and decreased priority a network consumer can starve a modestly quick local consumer. Throttling provides a remedy for this.</p></div>
         </td>
         <td valign="top">
           <div class="navigation">



Mime
View raw message