You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@activemq.apache.org by bu...@apache.org on 2015/08/17 17:21:23 UTC
svn commit: r962139 - in /websites/production/activemq/content:
cache/main.pageCache virtual-destinations.html
Author: buildbot
Date: Mon Aug 17 15:21:23 2015
New Revision: 962139
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 Aug 17 15:21:23 2015
@@ -107,7 +107,7 @@
</beans>
]]></script>
-</div></div>Note that making a topic virtual does add a small CPU overhead when sending messages to the topic but it is fairly small.<div class="table-wrap"><table class="confluenceTable"><tbody><tr><th colspan="1" rowspan="1" class="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 to fanout such that sends occur in parallel. This allows the journal to batch writes which will reduce disk io (5.12)</td></tr></tbody></table></div><p> </p><h2 id="VirtualDestinations-CompositeDestinations">Composite Destinations</h2><p>Composite Destinations allow for one-to-many relationships on individual destinations; 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><compositeQueue/></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><div class="code panel pdl" style="border-width: 1px;"><div class="codeContent panelContent pdl">
+</div></div>Note that making a topic virtual does add a small CPU overhead when sending messages to the topic but it is fairly small.<div class="table-wrap"><table class="confluenceTable"><tbody><tr><th colspan="1" rowspan="1" class="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 to 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></tbody></table></div><p> </p><h2 id="VirtualDestinations-CompositeDestinations">Composite Destinations</h2><p>Composite Destinations allow for one-to-many relationships on individual destinations; 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><compositeQueue/></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>B
AR</code>.</p><div class="code panel pdl" style="border-width: 1px;"><div class="codeContent panelContent pdl">
<script class="brush: xml; gutter: false; theme: Default" type="syntaxhighlighter"><![CDATA[
<beans
xmlns="http://www.springframework.org/schema/beans"