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"><