activemq-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From build...@apache.org
Subject svn commit: r962139 - in /websites/production/activemq/content: cache/main.pageCache virtual-destinations.html
Date Mon, 17 Aug 2015 15:21:23 GMT
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>&#160;</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>&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><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>&#160;</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>&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>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[
 &lt;beans 
   xmlns=&quot;http://www.springframework.org/schema/beans&quot; 



Mime
View raw message