Author: buildbot
Date: Mon Feb 19 13:23:48 2018
New Revision: 1025595

Log:
Production update by buildbot for activemq

Modified:
    websites/production/activemq/content/cache/main.pageCache
    websites/production/activemq/content/virtual-destinations.html

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

Modified: websites/production/activemq/content/virtual-destinations.html
==============================================================================
--- websites/production/activemq/content/virtual-destinations.html (original)
+++ websites/production/activemq/content/virtual-destinations.html Mon Feb 19 
13:23:48 2018
@@ -71,7 +71,7 @@
   <tbody>
         <tr>
         <td valign="top" width="100%">
-<div class="wiki-content maincontent"><p><em>Virtual Destinations</em> allow 
us to create logical destinations that clients can use to produce and consume 
from but which map onto one or more <em>physical destinations</em>. It allows 
us to provide more flexible loosely coupled messaging configurations.</p><h2 
id="VirtualDestinations-VirtualTopics">Virtual Topics</h2><p>The idea behind 
<em>publish subscribe</em> is a great one. Allow producers to be decoupled from 
consumers so that they do not even know how many consumers are interested in 
the messages they publish. The JMS specification defines support for durable 
topics however they have limitations as we will describe...</p><h3 
id="VirtualDestinations-ThelimitationsofJMSdurabletopics">The limitations of 
JMS durable topics</h3><p>A JMS durable subscriber MessageConsumer is created 
with a unique JMS clientID and durable subscriber name. To be JMS compliant 
only one JMS connection can be active at any point in time for one JMS clientI
 D, and only one consumer can be active for a clientID and subscriber name. 
i.e., only <strong>one</strong> thread can be actively consuming from a given 
logical topic subscriber. This means we cannot implement</p><ul><li>load 
balancing of messages.</li><li>fast failover of the subscriber if that one 
process running that one consumer thread dies.</li></ul><p>Now <em>queue</em> 
semantics in JMS offer the ability to load balance work across a number of 
consumers in a reliable way - allowing many threads, processes and machines to 
be used to process messages. Then we have sophisticated sticky load balancing 
techniques like <a shape="rect" href="message-groups.html">Message Groups</a> 
to load balance and parallelise work while maintaining ordering.</p><p>Another 
added benefit of having physical queues for each logical topic subscriber is we 
can then monitor the queue depths via <a shape="rect" href="jmx.html">JMX</a> 
to monitor system performance together with being able to browse these 
 physical queues.</p><h3 
id="VirtualDestinations-VirtualTopicstotherescue">Virtual Topics to the 
rescue</h3><p>The idea behind virtual topics is that producers send to a topic 
in the usual JMS way. Consumers can continue to use the Topic semantics in the 
JMS specification. However if the topic is virtual, consumer can consume from a 
physical queue for a logical topic subscription, allowing many consumers to be 
running on many machines &amp; threads to load balance the load.</p><p>E.g., 
let's say we have a topic called <strong>VirtualTopic.Orders</strong>. (Where 
the prefix VirtualTopic. indicates its a virtual topic). And we logically want 
to send orders to systems A and B. Now with regular durable topics we'd create 
a JMS consumer for clientID_A and "A" along with clientID_B and "B".</p><p>With 
virtual topics we can just go right ahead and consume to queue 
<strong>Consumer.A.VirtualTopic.Orders</strong> to be a consumer for system A 
or consume to <strong>Consumer.B.VirtualTopic.Orde
 rs</strong> to be a consumer for system B.</p><p>We can now have a pool of 
consumers for each system which then compete for messages for systems A or B 
such that all the messages for system A are processed exactly once and 
similarly for system B.</p><h3 
id="VirtualDestinations-Customizingtheout-of-the-boxdefaults">Customizing the 
out-of-the-box defaults</h3><p>The out-of-the-box defaults are described above. 
Namely that the only virtual topics available must be within the 
<strong>VirtualTopic.&gt;</strong> namespace and that the consumer queues are 
named <strong>Consumer.*.VirtualTopic.&gt;</strong>.</p><p>You can configure 
this to use whatever naming convention you wish. The following <a shape="rect" 
class="external-link" 
href="https://svn.apache.org/repos/asf/incubator/activemq/trunk/activemq-unit-tests/src/test/resources/org/apache/activemq/broker/virtual/global-virtual-topics.xml";>example</a>
 shows how to make all topics virtual topics. The example below is using the 
name <stron
 g>&gt;</strong> to indicate 'match all topics'. You could use this wildcard to 
apply different virtual topic policies in different hierarchies.</p><pre><span 
style="color: rgb(0,0,0);">&lt;destinationInterceptors&gt; 
</span></pre><pre><span style="color: rgb(0,0,0);"> 
&lt;virtualDestinationInterceptor&gt; </span></pre><pre><span style="color: 
rgb(0,0,0);"> &lt;virtualDestinations&gt; </span></pre><pre><span style="color: 
rgb(0,0,0);"> &lt;virtualTopic name="&gt;" prefix="VirtualTopicConsumers.*." 
selectorAware="false"/&gt; </span>   </pre><pre>   
&lt;/virtualDestinations&gt;</pre><pre><span style="color: rgb(0,0,0);"> 
&lt;/virtualDestinationInterceptor&gt; </span></pre><pre><span style="color: 
rgb(0,0,0);">&lt;/destinationInterceptors&gt;</span></pre><p>&#160;</p><p>Note 
that making a topic virtual does add a small CPU overhead when sending messages 
to the topic but it is fairly small.</p><div class="table-wrap"><table 
class="confluenceTable"><tbody><tr><th colspan="1" rowspan="1" c
 lass="confluenceTh">Option</th><th colspan="1" rowspan="1" 
class="confluenceTh">Default</th><th colspan="1" rowspan="1" 
class="confluenceTh">Description</th></tr><tr><td colspan="1" rowspan="1" 
class="confluenceTd">selectorAware</td><td colspan="1" rowspan="1" 
class="confluenceTd">false</td><td colspan="1" rowspan="1" 
class="confluenceTd">only messages that match one of the existing subscribers 
are actually dispatched. Using this option prevents the build up of unmatched 
messages when selectors are used by exclusive consumers</td></tr><tr><td 
colspan="1" rowspan="1" class="confluenceTd">local</td><td colspan="1" 
rowspan="1" class="confluenceTd">false</td><td colspan="1" rowspan="1" 
class="confluenceTd">when true, don't fan out messages that were received over 
a network</td></tr><tr><td colspan="1" rowspan="1" 
class="confluenceTd">concurrentSend</td><td colspan="1" rowspan="1" 
class="confluenceTd">false</td><td colspan="1" rowspan="1" 
class="confluenceTd">when true, use an executor t
 o fanout such that sends occur in parallel. This allows the journal to batch 
writes which will reduce disk io (5.12)</td></tr><tr><td colspan="1" 
rowspan="1" class="confluenceTd">transactedSend</td><td colspan="1" rowspan="1" 
class="confluenceTd">false</td><td colspan="1" rowspan="1" 
class="confluenceTd">when true, use a transaction for fanout sends such that 
there is a single disk sync. A local broker transaction will be created if 
there is no client transaction (5.13)</td></tr><tr><td colspan="1" rowspan="1" 
class="confluenceTd"><span>dropOnResourceLimit</span></td><td colspan="1" 
rowspan="1" class="confluenceTd">false</td><td colspan="1" rowspan="1" 
class="confluenceTd">when true, ignore any ResourceAllocationException thrown 
during fanout (see: sendFailIfNoSpace policy entry) 
(5.16)</td></tr></tbody></table></div><p>&#160;</p><h2 
id="VirtualDestinations-CompositeDestinations">Composite 
Destinations</h2><p>Composite Destinations allow for one-to-many relationships 
on individual d
 estinations; the main use case is for <em>composite queues</em>. For example 
when a message is sent to queue A you may want to forward it also to queues B 
and C and topic D. Composite destinations are then a mapping from a virtual 
destination to a collection of other physical destinations. In this case the 
mapping is broker side and the client is unaware of the mapping between the 
destinations. This is different from client side <a shape="rect" 
href="composite-destinations.html">Composite Destinations</a> where the client 
uses a URL notation to specify the actual physical destinations that a message 
must be sent to.</p><p>The following <a shape="rect" class="external-link" 
href="http://svn.apache.org/repos/asf/incubator/activemq/trunk/activemq-unit-tests/src/test/resources/org/apache/activemq/broker/virtual/composite-queue.xml";>example</a>
 shows how to set up a <strong>&lt;compositeQueue/&gt;</strong> element in the 
XML configuration so that when a message is sent to <code>MY.QUEUE<
 /code> then it is really forwarded to the physical queue <code>FOO</code> and 
the topic <code>BAR</code>.</p><pre><span style="color: 
rgb(0,0,0);">&lt;destinationInterceptors&gt;</span></pre><pre><span 
style="color: rgb(0,0,0);"> &lt;virtualDestinationInterceptor&gt; 
</span></pre><pre><span style="color: rgb(0,0,0);"> &lt;virtualDestinations&gt; 
</span></pre><pre><span style="color: rgb(0,0,0);"> &lt;compositeQueue 
name="MY.QUEUE"&gt;</span></pre><pre><span style="color: rgb(0,0,0);"> 
&lt;forwardTo&gt;</span></pre><pre><span style="color: rgb(0,0,0);"> &lt;queue 
physicalName="FOO" /&gt; </span></pre><pre><span style="color: rgb(0,0,0);"> 
&lt;topic physicalName="BAR" /&gt;</span></pre><pre><span style="color: 
rgb(0,0,0);"> &lt;/forwardTo&gt;</span></pre><pre><span style="color: 
rgb(0,0,0);"> &lt;/compositeQueue&gt;</span></pre><pre><span style="color: 
rgb(0,0,0);"> &lt;/virtualDestinations&gt;</span></pre><pre><span style="color: 
rgb(0,0,0);"> &lt;/virtualDestinationInterceptor&gt;</
 span></pre><pre><span style="color: 
rgb(0,0,0);">&lt;/destinationInterceptors&gt;</span></pre><p>&#160;</p><p>By 
default, subscribers cannot consume messages directly from a composite queue or 
topic - it is a logical construct only. Given the configuration above, 
subscribers can only consume messages from <code>FOO</code> and 
<code>BAR</code>; but not <code>MY.QUEUE</code>.</p><p>This behaviour can be 
altered to implement use cases such as watching a queue by sending the same 
messages to a notification topic (wire tapping), by setting the optionally set 
<code>forwardOnly</code> attribute to false.</p><pre>&lt;compositeQueue 
name="IncomingOrders" forwardOnly="false"&gt; </pre><pre>   
&lt;forwardTo&gt;</pre><pre>    &lt;topic physicalName="Notifications" 
/&gt;</pre><pre>   &lt;/forwardTo&gt;</pre><pre> 
&lt;/compositeQueue&gt;</pre><p>&#160;</p><p>Messages sent to 
<code>IncomingOrders</code> will all be copied and forwarded to 
<code>Notifications</code>, before being placed on the phys
 ical <code>IncomingOrders</code> queue for consumption by 
subscribers.</p><p>Where the <code>forwardOnly</code> attribute is not defined 
or is set to <code>true</code>, there is no logical difference between a 
<code>compositeQueue</code> and a <code>compositeTopic</code> - they can be 
used interchangeably. It is only when a composite destination is made physical 
through the use of <code>forwardOnly</code> that the choice of 
<code>compositeTopic</code>/<code>compositeQueue</code> has an impact on 
behavior.</p><h3 id="VirtualDestinations-Usingfiltereddestinations">Using 
filtered destinations</h3><p>From Apache ActiveMQ <strong>4.2</strong> onwards 
you can now use selectors to define virtual destinations.</p><p>You may wish to 
create a virtual destination which forwards messages to multiple destinations 
but applying a selector first to decide if the message really does have to go 
to a particular destination.</p><p>The following example shows how a message 
sent to the virtual destinatio
 n <strong>MY.QUEUE</strong> will be forwarded to <strong>FOO</strong> and 
<strong>BAR</strong> if the selectors 
match</p><pre>&lt;destinationInterceptors&gt; 
&lt;virtualDestinationInterceptor&gt; &lt;virtualDestinations&gt; </pre><pre>   
&lt;compositeQueue name="MY.QUEUE"&gt;</pre><pre>    
&lt;forwardTo&gt;</pre><pre>     &lt;filteredDestination selector="odd = 'yes'" 
queue="FOO"/&gt;</pre><pre>     &lt;filteredDestination selector="i = 5" 
topic="BAR"/&gt;</pre><pre>    &lt;/forwardTo&gt;</pre><pre>  
&lt;/compositeQueue&gt;</pre><pre>&lt;/virtualDestinations&gt; 
&lt;/virtualDestinationInterceptor&gt; 
&lt;/destinationInterceptors&gt;</pre><p>&#160;</p><h2 
id="VirtualDestinations-AvoidingDuplicateMessageinaNetworkofBrokers">Avoiding 
Duplicate Message in a Network of Brokers</h2><p><strong>TLDR</strong>: bridge 
consumer queues or virtual topics, not both.</p><p>Typically you would network 
consumer queues. In this case it is important to not bridge any normal topic 
consumer on the virtu
 al topic because any forwarded message would again get fanned out to consumer 
queues on the networked broker, leading to duplicates.</p><p>It is also 
possible to bridge the virtual topic in which case it is necessary exclude the 
consumer queues from any network connector configuration.&#160;</p><p>Here is 
an example of how to do that with a network bridge that will forward all queues 
and topics by default:</p><pre><span style="color: 
rgb(0,0,0);">&lt;networkConnectors&gt; &lt;networkConnector uri="static://(<a 
shape="rect" href="tcp://localhost:61617" 
rel="nofollow">tcp://localhost:61617</a>)"&gt;</span></pre><pre><span 
style="color: rgb(0,0,0);"> &lt;excludedDestinations&gt; 
</span></pre><pre><span style="color: rgb(0,0,0);"> &lt;queue 
physicalName="Consumer.*.VirtualTopic.&gt;"/&gt; </span></pre><pre><span 
style="color: rgb(0,0,0);"> &lt;/excludedDestinations&gt; 
</span></pre><pre><span style="color: rgb(0,0,0);">&lt;/networkConnector&gt; 
&lt;/networkConnectors&gt;</span></pre><p>
 &#160;</p></div>
+<div class="wiki-content maincontent"><p><em>Virtual Destinations</em> allow 
us to create logical destinations that clients can use to produce and consume 
from but which map onto one or more <em>physical destinations</em>. It allows 
us to provide more flexible loosely coupled messaging configurations.</p><h2 
id="VirtualDestinations-VirtualTopics">Virtual Topics</h2><p>The idea behind 
<em>publish subscribe</em> is a great one. Allow producers to be decoupled from 
consumers so that they do not even know how many consumers are interested in 
the messages they publish. The JMS specification defines support for durable 
topics however they have limitations as we will describe...</p><h3 
id="VirtualDestinations-ThelimitationsofJMSdurabletopics">The limitations of 
JMS durable topics</h3><p>A JMS durable subscriber MessageConsumer is created 
with a unique JMS clientID and durable subscriber name. To be JMS compliant 
only one JMS connection can be active at any point in time for one JMS clientI
 D, and only one consumer can be active for a clientID and subscriber name. 
i.e., only <strong>one</strong> thread can be actively consuming from a given 
logical topic subscriber. This means we cannot implement</p><ul><li>load 
balancing of messages.</li><li>fast failover of the subscriber if that one 
process running that one consumer thread dies.</li></ul><p>Now <em>queue</em> 
semantics in JMS offer the ability to load balance work across a number of 
consumers in a reliable way - allowing many threads, processes and machines to 
be used to process messages. Then we have sophisticated sticky load balancing 
techniques like <a shape="rect" href="message-groups.html">Message Groups</a> 
to load balance and parallelise work while maintaining ordering.</p><p>Another 
added benefit of having physical queues for each logical topic subscriber is we 
can then monitor the queue depths via <a shape="rect" href="jmx.html">JMX</a> 
to monitor system performance together with being able to browse these 
 physical queues.</p><h3 
id="VirtualDestinations-VirtualTopicstotherescue">Virtual Topics to the 
rescue</h3><p>The idea behind virtual topics is that producers send to a topic 
in the usual JMS way. Consumers can continue to use the Topic semantics in the 
JMS specification. However if the topic is virtual, consumer can consume from a 
physical queue for a logical topic subscription, allowing many consumers to be 
running on many machines &amp; threads to load balance the load.</p><p>E.g., 
let's say we have a topic called <strong>VirtualTopic.Orders</strong>. (Where 
the prefix VirtualTopic. indicates its a virtual topic). And we logically want 
to send orders to systems A and B. Now with regular durable topics we'd create 
a JMS consumer for clientID_A and "A" along with clientID_B and "B".</p><p>With 
virtual topics we can just go right ahead and consume to queue 
<strong>Consumer.A.VirtualTopic.Orders</strong> to be a consumer for system A 
or consume to <strong>Consumer.B.VirtualTopic.Orde
 rs</strong> to be a consumer for system B.</p><p>We can now have a pool of 
consumers for each system which then compete for messages for systems A or B 
such that all the messages for system A are processed exactly once and 
similarly for system B.</p><h3 
id="VirtualDestinations-Customizingtheout-of-the-boxdefaults">Customizing the 
out-of-the-box defaults</h3><p>The out-of-the-box defaults are described above. 
Namely that the only virtual topics available must be within the 
<strong>VirtualTopic.&gt;</strong> namespace and that the consumer queues are 
named <strong>Consumer.*.VirtualTopic.&gt;</strong>.</p><p>You can configure 
this to use whatever naming convention you wish. The following <a shape="rect" 
class="external-link" 
href="https://svn.apache.org/repos/asf/incubator/activemq/trunk/activemq-unit-tests/src/test/resources/org/apache/activemq/broker/virtual/global-virtual-topics.xml";>example</a>
 shows how to make all topics virtual topics. The example below is using the 
name <stron
 g>&gt;</strong> to indicate 'match all topics'. You could use this wildcard to 
apply different virtual topic policies in different hierarchies.</p><pre><span 
style="color: rgb(0,0,0);">&lt;destinationInterceptors&gt; 
</span></pre><pre><span style="color: rgb(0,0,0);"> 
&lt;virtualDestinationInterceptor&gt; </span></pre><pre><span style="color: 
rgb(0,0,0);"> &lt;virtualDestinations&gt; </span></pre><pre><span style="color: 
rgb(0,0,0);"> &lt;virtualTopic name="&gt;" prefix="VirtualTopicConsumers.*." 
selectorAware="false"/&gt; </span>   </pre><pre>   
&lt;/virtualDestinations&gt;</pre><pre><span style="color: rgb(0,0,0);"> 
&lt;/virtualDestinationInterceptor&gt; </span></pre><pre><span style="color: 
rgb(0,0,0);">&lt;/destinationInterceptors&gt;</span></pre><p>&#160;</p><p>Note 
that making a topic virtual does add a small CPU overhead when sending messages 
to the topic but it is fairly small.</p><div class="table-wrap"><table 
class="confluenceTable"><tbody><tr><th colspan="1" rowspan="1" c
 lass="confluenceTh">Option</th><th colspan="1" rowspan="1" 
class="confluenceTh">Default</th><th colspan="1" rowspan="1" 
class="confluenceTh">Description</th></tr><tr><td colspan="1" rowspan="1" 
class="confluenceTd">selectorAware</td><td colspan="1" rowspan="1" 
class="confluenceTd">false</td><td colspan="1" rowspan="1" 
class="confluenceTd">only messages that match one of the existing subscribers 
are actually dispatched. Using this option prevents the build up of unmatched 
messages when selectors are used by exclusive consumers</td></tr><tr><td 
colspan="1" rowspan="1" class="confluenceTd">local</td><td colspan="1" 
rowspan="1" class="confluenceTd">false</td><td colspan="1" rowspan="1" 
class="confluenceTd">when true, don't fan out messages that were received over 
a network</td></tr><tr><td colspan="1" rowspan="1" 
class="confluenceTd">concurrentSend</td><td colspan="1" rowspan="1" 
class="confluenceTd">false</td><td colspan="1" rowspan="1" 
class="confluenceTd">when true, use an executor t
 o fanout such that sends occur in parallel. This allows the journal to batch 
writes which will reduce disk io (5.12)</td></tr><tr><td colspan="1" 
rowspan="1" class="confluenceTd">transactedSend</td><td colspan="1" rowspan="1" 
class="confluenceTd">false</td><td colspan="1" rowspan="1" 
class="confluenceTd">when true, use a transaction for fanout sends such that 
there is a single disk sync. A local broker transaction will be created if 
there is no client transaction (5.13)</td></tr><tr><td colspan="1" rowspan="1" 
class="confluenceTd"><span>dropOnResourceLimit</span></td><td colspan="1" 
rowspan="1" class="confluenceTd">false</td><td colspan="1" rowspan="1" 
class="confluenceTd">when true, ignore any ResourceAllocationException thrown 
during fanout (see: sendFailIfNoSpace policy entry) 
(5.16)</td></tr></tbody></table></div><p>&#160;</p><h2 
id="VirtualDestinations-CompositeDestinations">Composite 
Destinations</h2><p>Composite Destinations allow for one-to-many relationships 
on individual d
 estinations; the main use case is for <em>composite queues</em>. For example 
when a message is sent to queue A you may want to forward it also to queues B 
and C and topic D. Composite destinations are then a mapping from a virtual 
destination to a collection of other physical destinations. In this case the 
mapping is broker side and the client is unaware of the mapping between the 
destinations. This is different from client side <a shape="rect" 
href="composite-destinations.html">Composite Destinations</a> where the client 
uses a URL notation to specify the actual physical destinations that a message 
must be sent to.</p><p>The following <a shape="rect" class="external-link" 
href="http://svn.apache.org/repos/asf/incubator/activemq/trunk/activemq-unit-tests/src/test/resources/org/apache/activemq/broker/virtual/composite-queue.xml";>example</a>
 shows how to set up a <strong>&lt;compositeQueue/&gt;</strong> element in the 
XML configuration so that when a message is sent to <code>MY.QUEUE<
 /code> then it is really forwarded to the physical queue <code>FOO</code> and 
the topic <code>BAR</code>.</p><pre><span style="color: 
rgb(0,0,0);">&lt;destinationInterceptors&gt;</span></pre><pre><span 
style="color: rgb(0,0,0);"> &lt;virtualDestinationInterceptor&gt; 
</span></pre><pre><span style="color: rgb(0,0,0);"> &lt;virtualDestinations&gt; 
</span></pre><pre><span style="color: rgb(0,0,0);"> &lt;compositeQueue 
name="MY.QUEUE"&gt;</span></pre><pre><span style="color: rgb(0,0,0);"> 
&lt;forwardTo&gt;</span></pre><pre><span style="color: rgb(0,0,0);"> &lt;queue 
physicalName="FOO" /&gt; </span></pre><pre><span style="color: rgb(0,0,0);"> 
&lt;topic physicalName="BAR" /&gt;</span></pre><pre><span style="color: 
rgb(0,0,0);"> &lt;/forwardTo&gt;</span></pre><pre><span style="color: 
rgb(0,0,0);"> &lt;/compositeQueue&gt;</span></pre><pre><span style="color: 
rgb(0,0,0);"> &lt;/virtualDestinations&gt;</span></pre><pre><span style="color: 
rgb(0,0,0);"> &lt;/virtualDestinationInterceptor&gt;</
 span></pre><pre><span style="color: 
rgb(0,0,0);">&lt;/destinationInterceptors&gt;</span></pre><p>&#160;</p><p>By 
default, subscribers cannot consume messages directly from a composite queue or 
topic - it is a logical construct only. Given the configuration above, 
subscribers can only consume messages from <code>FOO</code> and 
<code>BAR</code>; but not <code>MY.QUEUE</code>.</p><p>This behaviour can be 
altered to implement use cases such as watching a queue by sending the same 
messages to a notification topic (wire tapping), by setting the optionally set 
<code>forwardOnly</code> attribute to false.</p><pre>&lt;compositeQueue 
name="IncomingOrders" forwardOnly="false"&gt; </pre><pre>   
&lt;forwardTo&gt;</pre><pre>    &lt;topic physicalName="Notifications" 
/&gt;</pre><pre>   &lt;/forwardTo&gt;</pre><pre> 
&lt;/compositeQueue&gt;</pre><p>&#160;</p><p>Messages sent to 
<code>IncomingOrders</code> will all be copied and forwarded to 
<code>Notifications</code>, before being placed on the phys
 ical <code>IncomingOrders</code> queue for consumption by 
subscribers.</p><p>Where the <code>forwardOnly</code> attribute is not defined 
or is set to <code>true</code>, there is no logical difference between a 
<code>compositeQueue</code> and a <code>compositeTopic</code> - they can be 
used interchangeably. It is only when a composite destination is made physical 
through the use of <code>forwardOnly</code> that the choice of 
<code>compositeTopic</code>/<code>compositeQueue</code> has an impact on 
behavior.</p><h3 id="VirtualDestinations-Usingfiltereddestinations">Using 
filtered destinations</h3><p>From Apache ActiveMQ <strong>4.2</strong> onwards 
you can now use selectors to define virtual destinations.</p><p>You may wish to 
create a virtual destination which forwards messages to multiple destinations 
but applying a selector first to decide if the message really does have to go 
to a particular destination.</p><p>The following example shows how a message 
sent to the virtual destinatio
 n <strong>MY.QUEUE</strong> will be forwarded to <strong>FOO</strong> and 
<strong>BAR</strong> if the selectors 
match</p><pre>&lt;destinationInterceptors&gt; 
&lt;virtualDestinationInterceptor&gt; &lt;virtualDestinations&gt; </pre><pre>   
&lt;compositeQueue name="MY.QUEUE"&gt;</pre><pre>    
&lt;forwardTo&gt;</pre><pre>     &lt;filteredDestination selector="odd = 'yes'" 
queue="FOO"/&gt;</pre><pre>     &lt;filteredDestination selector="i = 5" 
topic="BAR"/&gt;</pre><pre>    &lt;/forwardTo&gt;</pre><pre>  
&lt;/compositeQueue&gt;</pre><pre>&lt;/virtualDestinations&gt; 
&lt;/virtualDestinationInterceptor&gt; 
&lt;/destinationInterceptors&gt;</pre><p>&#160;</p><h2 
id="VirtualDestinations-AvoidingDuplicateMessageinaNetworkofBrokers">Avoiding 
Duplicate Message in a Network of Brokers</h2><p><strong>TLDR</strong>: bridge 
consumer queues or virtual topics, not both.</p><p>Typically you would network 
consumer queues. In this case it is important to not bridge any normal topic 
consumer on the virtu
 al topic because any forwarded message would again get fanned out to consumer 
queues on the networked broker, leading to duplicates.</p><p>It is also 
possible to bridge the virtual topic in which case it is necessary exclude the 
consumer queues from any network connector configuration.&#160;</p><p>Here is 
an example of how to exclude virtual topic consumer queues:</p><pre><span 
style="color: rgb(0,0,0);">&lt;networkConnectors&gt; &lt;networkConnector 
uri="static://(<a shape="rect" href="tcp://localhost:61617" 
rel="nofollow">tcp://localhost:61617</a>)"&gt;</span></pre><pre><span 
style="color: rgb(0,0,0);"> &lt;excludedDestinations&gt; 
</span></pre><pre><span style="color: rgb(0,0,0);"> &lt;queue 
physicalName="Consumer.*.VirtualTopic.&gt;"/&gt; </span></pre><pre><span 
style="color: rgb(0,0,0);"> &lt;/excludedDestinations&gt; 
</span></pre><pre><span style="color: rgb(0,0,0);">&lt;/networkConnector&gt; 
&lt;/networkConnectors&gt;</span></pre><p>&#160;</p></div>
         </td>
         <td valign="top">
           <div class="navigation">


Reply via email to