Author: buildbot
Date: Thu May 10 10:24:09 2018
New Revision: 1029708
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 Thu May 10
10:24:09 2018
@@ -81,7 +81,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 & 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.></strong> namespace and that the consumer queues are
named <strong>Consumer.*.VirtualTopic.></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>></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);"><destinationInterceptors>
</span></pre><pre><span style="color: rgb(0,0,0);">
<virtualDestinationInterceptor> </span></pre><pre><span style="color:
rgb(0,0,0);"> <virtualDestinations> </span></pre><pre><span style="color:
rgb(0,0,0);"> <virtualTopic name=">" prefix="VirtualTopicConsumers.*."
selectorAware="false"/> </span> </pre><pre>
</virtualDestinations></pre><pre><span style="color: rgb(0,0,0);">
</virtualDestinationInterceptor> </span></pre><pre><span style="color:
rgb(0,0,0);"></destinationInterceptors></span></pre><p> </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> </p><h2
id="VirtualDestinations-VirtualSelectorCacheBrokerPlugin"><span style="color:
rgb(0,0,0);">VirtualSelectorCacheBrokerPlugin</span></h2><p><span style="
color: rgb(0,0,0);">When selectorAware=true, only active consumers are
condidered for selector matching. If consumers disconnect and reconnect they
will miss messages. The intent of selectorAware=true is to not have
messages build up. </span><span style="color:
rgb(0,0,0);">The virtualSelectorCacheBrokerPlugin provides a cache that
tracks the selectors associated with a destination by a consumers such that
they can apply in the absense of that consumer. In this way the just the
selected messages build up. The existing set of selectors can be persisted such
that it can be recovered on restart. the plugin is applied in the normal way to
the plugins section.</span></p><div class="code panel pdl" style="border-width:
1px;"><div class="codeContent panelContent pdl">
+<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 & 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.></strong> namespace and that the consumer queues are
named <strong>Consumer.*.VirtualTopic.></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>></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);"><destinationInterceptors>
</span></pre><pre><span style="color: rgb(0,0,0);">
<virtualDestinationInterceptor> </span></pre><pre><span style="color:
rgb(0,0,0);"> <virtualDestinations> </span></pre><pre><span style="color:
rgb(0,0,0);"> <virtualTopic name=">" prefix="VirtualTopicConsumers.*."
selectorAware="false"/> </span> </pre><pre>
</virtualDestinations></pre><pre><span style="color: rgb(0,0,0);">
</virtualDestinationInterceptor> </span></pre><pre><span style="color:
rgb(0,0,0);"></destinationInterceptors></span></pre><p> </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><tr><td
colspan="1" rowspan="1" class="confluenceTd"><p class="p1"><span
class="s1">setOriginalDestination</span></p></td><td colspan="1" rowspan="1"
class="confluenceTd">true</td><td colspa
n="1" rowspan="1" class="confluenceTd">when true, the destination on the
forwarded message is set to the consumer queue and the originalDestination
message property tracks the virtual topic
(5.16)</td></tr></tbody></table></div><p> </p><h2
id="VirtualDestinations-VirtualSelectorCacheBrokerPlugin"><span style="color:
rgb(0,0,0);">VirtualSelectorCacheBrokerPlugin</span></h2><p><span style="color:
rgb(0,0,0);">When selectorAware=true, only active consumers are condidered for
selector matching. If consumers disconnect and reconnect they will miss
messages. The intent of selectorAware=true is to not have messages build
up. </span><span style="color:
rgb(0,0,0);">The virtualSelectorCacheBrokerPlugin provides a cache that
tracks the selectors associated with a destination by a consumers such that
they can apply in the absense of that consumer. In this way the just the
selected messages build up. The existing set of selectors can be persisted such
that it can be recovere
d on restart. the plugin is applied in the normal way to the plugins
section.</span></p><div class="code panel pdl" style="border-width: 1px;"><div
class="codeContent panelContent pdl">
<pre class="brush: java; gutter: false; theme: Default"
style="font-size:12px;"><plugins>
<virtualSelectorCacheBrokerPlugin persistFile="<some
path>/selectorcache.data" />
</plugins></pre>
