activemq-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From build...@apache.org
Subject svn commit: r1025590 - in /websites/production/activemq/content: cache/main.pageCache virtual-destinations.html
Date Mon, 19 Feb 2018 11:24:00 GMT
Author: buildbot
Date: Mon Feb 19 11:24:00 2018
New Revision: 1025590

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 11:24:00 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>You have to make sure that the messages
sent to the <strong>Consumer.*.VirtualTopic.&gt;</strong> destination are
not forwarded when you're using both queue-based and non-queue based subscribers to the virtu
 al topic (that is, if you have normal topic subscribers to the virtual topic). If you use
Virtual Topics in a network of brokers, it is likely you will get duplicate messages if you
use the default network configuration. This is because a network node will not only forward
message sent to the virtual topic, but also the associated physical queues. To fix this, you
should disable forwarding messages on the associated physical queues.</p><p>Here
is an example of how to do that:</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 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>
         </td>
         <td valign="top">
           <div class="navigation">



Mime
View raw message