Author: buildbot
Date: Fri Jul 4 11:18:03 2014
New Revision: 914982
Log:
Production update by buildbot for camel
Modified:
websites/production/camel/content/cache/main.pageCache
websites/production/camel/content/disruptor.html
Modified: websites/production/camel/content/cache/main.pageCache
==============================================================================
Binary files - no diff available.
Modified: websites/production/camel/content/disruptor.html
==============================================================================
--- websites/production/camel/content/disruptor.html (original)
+++ websites/production/camel/content/disruptor.html Fri Jul 4 11:18:03 2014
@@ -84,103 +84,35 @@
<tbody>
<tr>
<td valign="top" width="100%">
-<div class="wiki-content maincontent"><h2
id="Disruptor-DisruptorComponent">Disruptor Component</h2>
-<p><strong>Available as of Camel 2.12</strong></p>
-
-<p>The <strong>disruptor:</strong> component provides asynchronous <a
shape="rect" class="external-link"
href="http://www.eecs.harvard.edu/~mdw/proj/seda/"; rel="nofollow">SEDA</a>
behavior much as the standard SEDA Component, but utilizes a <a shape="rect"
class="external-link" href="https://github.com/LMAX-Exchange/disruptor";
rel="nofollow">Disruptor</a> instead of a <a shape="rect" class="external-link"
href="http://docs.oracle.com/javase/1.5.0/docs/api/java/util/concurrent/BlockingQueue.html";
rel="nofollow">BlockingQueue</a> utilized by the standard <a shape="rect"
href="seda.html">SEDA</a>. Alternatively, a</p>
-
-<p><strong>disruptor-vm:</strong> endpoint is supported by this component,
providing an alternative to the standard <a shape="rect" href="vm.html">VM</a>.
As with the SEDA component, buffers of the <strong>disruptor:</strong>
endpoints are only visible within a <strong>single</strong> <a shape="rect"
href="camelcontext.html">CamelContext</a> and no support is provided for
persistence or recovery. The buffers of the *<strong>disruptor-vm:</strong>*
endpoints also provides support for communication across CamelContexts
instances so you can use this mechanism to communicate across web applications
(provided that <strong>camel-disruptor.jar</strong> is on the
<strong>system/boot</strong> classpath).</p>
-
-<p>The main advantage of choosing to use the Disruptor Component over the SEDA
or the VM Component is performance in use cases where there is high contention
between producer(s) and/or multicasted or concurrent Consumers. In those cases,
significant increases of throughput and reduction of latency has been observed.
Performance in scenarios without contention is comparable to the SEDA and VM
Components.</p>
-
-<p>The Disruptor is implemented with the intention of mimicing the behaviour
and options of the SEDA and VM Components as much as possible. The main
differences with the them are the following:</p>
-
-<ul><li>The buffer used is always bounded in size (default 1024
exchanges).</li><li>As a the buffer is always bouded, the default behaviour for
the Disruptor is to block while the buffer is full instead of throwing an
exception. This default behaviour may be configured on the component (see
options).</li><li>The Disruptor enpoints don't implement the BrowsableEndpoint
interface. As such, the exchanges currently in the Disruptor can't be
retrieved, only the amount of exchanges.</li><li>The Disruptor requires its
consumers (multicasted or otherwise) to be statically configured. Adding or
removing consumers on the fly requires complete flushing of all pending
exchanges in the Disruptor.</li><li>As a result of the reconfiguration: Data
sent over a Disruptor is directly processed and 'gone' if there is at least one
consumer, late joiners only get new exchanges published after they've
joined.</li><li>The <strong>pollTimeout</strong> option is not supported by the
Disruptor Component.</li>
<li>When a producer blocks on a full Disruptor, it does not respond to thread
interrupts.</li></ul>
-
-
-<p>Maven users will need to add the following dependency to their
<code>pom.xml</code> for this component:</p>
-<div class="code panel pdl" style="border-width: 1px;"><div class="codeContent
panelContent pdl">
-<script class="theme: Default; brush: java; gutter: false"
type="syntaxhighlighter"><![CDATA[
-<dependency>
+<div class="wiki-content maincontent"><h2
id="Disruptor-DisruptorComponent">Disruptor Component</h2><p><strong>Available
as of Camel 2.12</strong></p><p>The <strong>disruptor:</strong> component
provides asynchronous <a shape="rect" class="external-link"
href="http://www.eecs.harvard.edu/~mdw/proj/seda/"; rel="nofollow">SEDA</a>
behavior much as the standard SEDA Component, but utilizes a <a shape="rect"
class="external-link" href="https://github.com/LMAX-Exchange/disruptor";
rel="nofollow">Disruptor</a> instead of a <a shape="rect" class="external-link"
href="http://docs.oracle.com/javase/1.5.0/docs/api/java/util/concurrent/BlockingQueue.html";
rel="nofollow">BlockingQueue</a> utilized by the standard <a shape="rect"
href="seda.html">SEDA</a>. Alternatively,
a</p><p><strong>disruptor-vm:</strong> endpoint is supported by this component,
providing an alternative to the standard <a shape="rect" href="vm.html">VM</a>.
As with the SEDA component, buffers of the <strong>disruptor:</strong>
endpoints are only visible within a <strong>single</strong> <a shape="rect"
href="camelcontext.html">CamelContext</a> and no support is provided for
persistence or recovery. The buffers of the *<strong>disruptor-vm:</strong>*
endpoints also provides support for communication across CamelContexts
instances so you can use this mechanism to communicate across web applications
(provided that <strong>camel-disruptor.jar</strong> is on the
<strong>system/boot</strong> classpath).</p><p>The main advantage of choosing
to use the Disruptor Component over the SEDA or the VM Component is performance
in use cases where there is high contention between producer(s) and/or
multicasted or concurrent Consumers. In those cases, significant increases of
throughput and reduction of latency has been observed. Performance in scenarios
without contention is comparable to the SEDA and VM Components.</p><p>The
Disruptor is implemented with the intention of mimicing the behaviour and
options of the SEDA and
VM Components as much as possible. The main differences with the them are the
following:</p><ul><li>The buffer used is always bounded in size (default 1024
exchanges).</li><li>As a the buffer is always bouded, the default behaviour for
the Disruptor is to block while the buffer is full instead of throwing an
exception. This default behaviour may be configured on the component (see
options).</li><li>The Disruptor enpoints don't implement the BrowsableEndpoint
interface. As such, the exchanges currently in the Disruptor can't be
retrieved, only the amount of exchanges.</li><li>The Disruptor requires its
consumers (multicasted or otherwise) to be statically configured. Adding or
removing consumers on the fly requires complete flushing of all pending
exchanges in the Disruptor.</li><li>As a result of the reconfiguration: Data
sent over a Disruptor is directly processed and 'gone' if there is at least one
consumer, late joiners only get new exchanges published after they've
joined.</li>
<li>The <strong>pollTimeout</strong> option is not supported by the Disruptor
Component.</li><li>When a producer blocks on a full Disruptor, it does not
respond to thread interrupts.</li></ul><p>Maven users will need to add the
following dependency to their <code>pom.xml</code> for this component:</p><div
class="code panel pdl" style="border-width: 1px;"><div class="codeContent
panelContent pdl">
+<script class="theme: Default; brush: java; gutter: false"
type="syntaxhighlighter"><![CDATA[<dependency>
<groupId>org.apache.camel</groupId>
<artifactId>camel-disruptor</artifactId>
<version>x.x.x</version>
<!-- use the same version as your Camel core version -->
</dependency>
]]></script>
-</div></div>
-
-
-<h3 id="Disruptor-URIformat">URI format</h3>
-<div class="code panel pdl" style="border-width: 1px;"><div class="codeContent
panelContent pdl">
-<script class="theme: Default; brush: java; gutter: false"
type="syntaxhighlighter"><![CDATA[
- disruptor:someName[?options]
+</div></div><h3 id="Disruptor-URIformat">URI format</h3><div class="code panel
pdl" style="border-width: 1px;"><div class="codeContent panelContent pdl">
+<script class="theme: Default; brush: java; gutter: false"
type="syntaxhighlighter"><![CDATA[ disruptor:someName[?options]
]]></script>
-</div></div>
-<p>or</p>
-<div class="code panel pdl" style="border-width: 1px;"><div class="codeContent
panelContent pdl">
-<script class="theme: Default; brush: java; gutter: false"
type="syntaxhighlighter"><![CDATA[
- disruptor-vm:someName[?options]
+</div></div><p>or</p><div class="code panel pdl" style="border-width:
1px;"><div class="codeContent panelContent pdl">
+<script class="theme: Default; brush: java; gutter: false"
type="syntaxhighlighter"><![CDATA[ disruptor-vm:someName[?options]
]]></script>
-</div></div>
-
-<p>Where *<strong>someName</strong>* can be any string that uniquely
identifies the endpoint within the current <a shape="rect"
href="camelcontext.html">CamelContext</a> (or across contexts in case of<br
clear="none">
-*<strong>disruptor-vm:</strong>*).<br clear="none">
-You can append query options to the URI in the following format:</p>
-<div class="code panel pdl" style="border-width: 1px;"><div class="codeContent
panelContent pdl">
-<script class="theme: Default; brush: java; gutter: false"
type="syntaxhighlighter"><![CDATA[
- ?option=value&option=value&â¦
+</div></div><p>Where *<strong>someName</strong>* can be any string that
uniquely identifies the endpoint within the current <a shape="rect"
href="camelcontext.html">CamelContext</a> (or across contexts in case of<br
clear="none"> *<strong>disruptor-vm:</strong>*).<br clear="none"> You can
append query options to the URI in the following format:</p><div class="code
panel pdl" style="border-width: 1px;"><div class="codeContent panelContent pdl">
+<script class="theme: Default; brush: java; gutter: false"
type="syntaxhighlighter"><![CDATA[ ?option=value&option=value&â¦
]]></script>
-</div></div>
-
-
-<h3 id="Disruptor-Options">Options</h3>
-
-<p>All the following options are valid for both the
*<strong>disruptor:</strong>* and *<strong>disruptor-vm:</strong>*
components.</p>
-
-<div class="table-wrap"><table class="confluenceTable"><tbody><tr><th
colspan="1" rowspan="1" class="confluenceTh"><p> <strong>Name</strong>
</p></th><th colspan="1" rowspan="1" class="confluenceTh"><p>
<strong>Default</strong> </p></th><th colspan="1" rowspan="1"
class="confluenceTh"><p> <strong>Description</strong> </p></th></tr><tr><td
colspan="1" rowspan="1" class="confluenceTd"><p> size </p></td><td colspan="1"
rowspan="1" class="confluenceTd"><p> 1024 </p></td><td colspan="1" rowspan="1"
class="confluenceTd"><p>The maximum capacity of the Disruptors ringbuffer. Will
be effectively increased to the nearest power of two. <strong>Notice:</strong>
Mind if you use this option, then its the first endpoint being created with the
queue name, that determines the size. To make sure all endpoints use same size,
then configure the size option on all of them, or the first endpoint being
created.</p></td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><p>
bufferSize </p></td><td c
olspan="1" rowspan="1" class="confluenceTd"><p> </p></td><td colspan="1"
rowspan="1" class="confluenceTd"><p> <strong>Component only:</strong> The
maximum default size (capacity of the number of messages it can hold) of the
Disruptors ringbuffer. This option is used if size is not in
use.</p></td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><p>
queueSize </p></td><td colspan="1" rowspan="1"
class="confluenceTd"><p> </p></td><td colspan="1" rowspan="1"
class="confluenceTd"><p> <strong>Component only:</strong> Additional option to
specify the <em>bufferSize</em> to maintain maximum compatibility
with the <a shape="rect" href="seda.html">SEDA</a>
Component.</p></td></tr><tr><td colspan="1" rowspan="1"
class="confluenceTd"><p> concurrentConsumers </p></td><td colspan="1"
rowspan="1" class="confluenceTd"><p> 1 </p></td><td colspan="1" rowspan="1"
class="confluenceTd"><p> Number of concurrent threads processing exchanges.
</p></td></tr><tr><td colspan="1
" rowspan="1" class="confluenceTd"><p> waitForTaskToComplete </p></td><td
colspan="1" rowspan="1" class="confluenceTd"><p> IfReplyExpected </p></td><td
colspan="1" rowspan="1" class="confluenceTd"><p>Option to specify whether the
caller should wait for the async task to complete or not before continuing. The
following three options are supported: <em>Always</em>, <em>Never</em> or
<em>IfReplyExpected</em>. The first two values are self-explanatory. The last
value, <em>IfReplyExpected</em>, will only wait if the message is <a
shape="rect" href="request-reply.html">Request Reply</a> based. See more
information about <a shape="rect" href="async.html">Async</a> messaging.
</p></td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><p> timeout
</p></td><td colspan="1" rowspan="1" class="confluenceTd"><p> 30000
</p></td><td colspan="1" rowspan="1" class="confluenceTd"><p> Timeout (in
milliseconds) before a producer will stop waiting for an asynchronous task to
complete. See <em>wai
tForTaskToComplete</em> and <a shape="rect" href="async.html">Async</a> for
more details. You can disable timeout by using 0 or a negative value.
</p></td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><p>
defaultMultipleConsumers </p></td><td colspan="1" rowspan="1"
class="confluenceTd"><p> </p></td><td colspan="1" rowspan="1"
class="confluenceTd"><p> <strong>Component only:</strong> Allows to set the
default allowance of multiple consumers for endpoints created by this comonent
used when <em>multipleConsumers</em> is not provided.</p></td></tr><tr><td
colspan="1" rowspan="1" class="confluenceTd"><p> limitConcurrentConsumers
</p></td><td colspan="1" rowspan="1" class="confluenceTd"><p> true </p></td><td
colspan="1" rowspan="1" class="confluenceTd"><p> Whether to limit the number of
concurrentConsumers to the maximum of 500. By default, an exception will be
thrown if a Disruptor endpoint is configured with a greater number. You can
disable that check by turning this
option off. </p></td></tr><tr><td colspan="1" rowspan="1"
class="confluenceTd"><p> blockWhenFull </p></td><td colspan="1" rowspan="1"
class="confluenceTd"><p> true </p></td><td colspan="1" rowspan="1"
class="confluenceTd"><p> Whether a thread that sends messages to a full
Disruptor will block until the ringbuffer's capacity is no longer exhausted. By
default, the calling thread will block and wait until the message can be
accepted. By disabling this option, an exception will be thrown stating that
the queue is full.</p></td></tr><tr><td colspan="1" rowspan="1"
class="confluenceTd"><p> defaultBlockWhenFull </p></td><td colspan="1"
rowspan="1" class="confluenceTd"><p> </p></td><td colspan="1" rowspan="1"
class="confluenceTd"><p> <strong>Component only:</strong> Allows to set the
default producer behaviour when the ringbuffer is full for endpoints created by
this comonent used when <em>blockWhenFull</em> is not provided.
</p></td></tr><tr><td colspan="1" rowspan="1" class="conflue
nceTd"><p> waitStrategy </p></td><td colspan="1" rowspan="1"
class="confluenceTd"><p> Blocking </p></td><td colspan="1" rowspan="1"
class="confluenceTd"><p> Defines the strategy used by consumer threads to wait
on new exchanges to be published. The options allowed are:<em>Blocking</em>,
<em>Sleeping</em>, <em>BusySpin</em> and <em>Yielding</em>. Refer to the
section below for more information on this subject </p></td></tr><tr><td
colspan="1" rowspan="1" class="confluenceTd"><p>defaultWaitStrategy</p></td><td
colspan="1" rowspan="1" class="confluenceTd"><p> </p></td><td colspan="1"
rowspan="1" class="confluenceTd"><p> <strong>Component only:</strong> Allows to
set the default wait strategy for endpoints created by this comonent used when
<em>waitStrategy</em> is not provided.</p></td></tr><tr><td colspan="1"
rowspan="1" class="confluenceTd"><p> producerType </p></td><td colspan="1"
rowspan="1" class="confluenceTd"><p> Multi </p></td><td colspan="1" rowspan="1"
class="confluenceT
d"><p> Defines the producers allowed on the Disruptor. The options allowed
are: <em>Multi</em> to allow multiple producers and <em>Single</em> to enable
certain optimizations only allowed when one concurrent producer (on one thread
or otherwise synchronized) is active.</p></td></tr><tr><td colspan="1"
rowspan="1" class="confluenceTd"><p>defaultProducerType</p></td><td colspan="1"
rowspan="1" class="confluenceTd"><p> </p></td><td colspan="1" rowspan="1"
class="confluenceTd"><p><strong>Component only:</strong> Allows to set the
default producer type for endpoints created by this comonent used when
<em>producerType</em> is not provided.</p></td></tr></tbody></table></div>
-
-
-<h3 id="Disruptor-Waitstrategies">Wait strategies</h3>
-<p>The wait strategy effects the type of waiting performed by the consumer
threads that are currently waiting for the next exchange to be published. The
following strategies can be chosen:</p>
-<div class="table-wrap"><table class="confluenceTable"><tbody><tr><th
colspan="1" rowspan="1" class="confluenceTh"><p>Name </p></th><th colspan="1"
rowspan="1" class="confluenceTh"><p> Description </p></th><th colspan="1"
rowspan="1" class="confluenceTh"><p> Advice </p></th></tr><tr><td colspan="1"
rowspan="1" class="confluenceTd"><p> Blocking </p></td><td colspan="1"
rowspan="1" class="confluenceTd"><p> Blocking strategy that uses a lock and
condition variable for Consumers waiting on a barrier. </p></td><td
colspan="1" rowspan="1" class="confluenceTd"><p>This strategy can be used when
throughput and low-latency are not as important as CPU
resource.</p></td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><p>
Sleeping </p></td><td colspan="1" rowspan="1" class="confluenceTd"><p> Sleeping
strategy that initially spins, then uses a Thread.yield(), and eventually for
the minimum number of nanos the OS and JVM will allow while the Consumers are
waiting on a barrier. </p></td><
td colspan="1" rowspan="1" class="confluenceTd"><p> This strategy is a good
compromise between performance and CPU resource. Latency spikes can occur after
quiet periods. </p></td></tr><tr><td colspan="1" rowspan="1"
class="confluenceTd"><p> BusySpin </p></td><td colspan="1" rowspan="1"
class="confluenceTd"><p> Busy Spin strategy that uses a busy spin loop for
Consumers waiting on a barrier. </p></td><td colspan="1" rowspan="1"
class="confluenceTd"><p> This strategy will use CPU resource to avoid syscalls
which can introduce latency jitter. It is best used when threads can be bound
to specific CPU cores. </p></td></tr><tr><td colspan="1" rowspan="1"
class="confluenceTd"><p> Yielding </p></td><td colspan="1" rowspan="1"
class="confluenceTd"><p> Yielding strategy that uses a Thread.yield() for
Consumers waiting on a barrier after an initially spinning. </p></td><td
colspan="1" rowspan="1" class="confluenceTd"><p> This strategy is a good
compromise between performance and CPU resource
without incurring significant latency spikes.
</p></td></tr></tbody></table></div>
-
-
-<h3 id="Disruptor-UseofRequestReply">Use of Request Reply</h3>
-<p>The Disruptor component supports using <a shape="rect"
href="request-reply.html">Request Reply</a>, where the caller will wait for the
Async route to complete. For instance:</p>
-<div class="code panel pdl" style="border-width: 1px;"><div class="codeContent
panelContent pdl">
-<script class="theme: Default; brush: java; gutter: false"
type="syntaxhighlighter"><![CDATA[
-from("mina:tcp://0.0.0.0:9876?textline=true&sync=true").to("disruptor:input");
+</div></div><h3 id="Disruptor-Options">Options</h3><p>All the following
options are valid for both the *<strong>disruptor:</strong>* and
*<strong>disruptor-vm:</strong>* components.</p><div class="table-wrap"><table
class="confluenceTable"><tbody><tr><th colspan="1" rowspan="1"
class="confluenceTh"><p><strong>Name</strong></p></th><th colspan="1"
rowspan="1" class="confluenceTh"><p><strong>Default</strong></p></th><th
colspan="1" rowspan="1"
class="confluenceTh"><p><strong>Description</strong></p></th></tr><tr><td
colspan="1" rowspan="1" class="confluenceTd"><p>size</p></td><td colspan="1"
rowspan="1" class="confluenceTd"><p>1024</p></td><td colspan="1" rowspan="1"
class="confluenceTd"><p>The maximum capacity of the Disruptors ringbuffer. Will
be effectively increased to the nearest power of two. <strong>Notice:</strong>
Mind if you use this option, then its the first endpoint being created with the
queue name, that determines the size. To make sure all endpoints use same size,
then
configure the size option on all of them, or the first endpoint being
created.</p></td></tr><tr><td colspan="1" rowspan="1"
class="confluenceTd"><p>bufferSize</p></td><td colspan="1" rowspan="1"
class="confluenceTd"><p> </p></td><td colspan="1" rowspan="1"
class="confluenceTd"><p><strong>Component only:</strong> The maximum default
size (capacity of the number of messages it can hold) of the Disruptors
ringbuffer. This option is used if size is not in use.</p></td></tr><tr><td
colspan="1" rowspan="1" class="confluenceTd"><p>queueSize</p></td><td
colspan="1" rowspan="1" class="confluenceTd"><p> </p></td><td colspan="1"
rowspan="1" class="confluenceTd"><p><strong>Component only:</strong> Additional
option to specify the <em>bufferSize</em> to maintain maximum
compatibility with the <a shape="rect" href="seda.html">SEDA</a>
Component.</p></td></tr><tr><td colspan="1" rowspan="1"
class="confluenceTd"><p>concurrentConsumers</p></td><td colspan="1" rowspan="1"
class
="confluenceTd"><p>1</p></td><td colspan="1" rowspan="1"
class="confluenceTd"><p>Number of concurrent threads processing
exchanges.</p></td></tr><tr><td colspan="1" rowspan="1"
class="confluenceTd"><p>waitForTaskToComplete</p></td><td colspan="1"
rowspan="1" class="confluenceTd"><p>IfReplyExpected</p></td><td colspan="1"
rowspan="1" class="confluenceTd"><p>Option to specify whether the caller should
wait for the async task to complete or not before continuing. The following
three options are supported: <em>Always</em>, <em>Never</em> or
<em>IfReplyExpected</em>. The first two values are self-explanatory. The last
value, <em>IfReplyExpected</em>, will only wait if the message is <a
shape="rect" href="request-reply.html">Request Reply</a> based. See more
information about <a shape="rect" href="async.html">Async</a>
messaging.</p></td></tr><tr><td colspan="1" rowspan="1"
class="confluenceTd"><p>timeout</p></td><td colspan="1" rowspan="1"
class="confluenceTd"><p>30000</p></td><td colspa
n="1" rowspan="1" class="confluenceTd"><p>Timeout (in milliseconds) before a
producer will stop waiting for an asynchronous task to complete. See
<em>waitForTaskToComplete</em> and <a shape="rect" href="async.html">Async</a>
for more details. You can disable timeout by using 0 or a negative
value.</p></td></tr><tr><td colspan="1" rowspan="1"
class="confluenceTd"><p>defaultMultipleConsumers</p></td><td colspan="1"
rowspan="1" class="confluenceTd"><p> </p></td><td colspan="1" rowspan="1"
class="confluenceTd"><p><strong>Component only:</strong> Allows to set the
default allowance of multiple consumers for endpoints created by this component
used when <em>multipleConsumers</em> is not provided.</p></td></tr><tr><td
colspan="1" rowspan="1" class="confluenceTd">multipleConsumers</td><td
colspan="1" rowspan="1" class="confluenceTd">false</td><td colspan="1"
rowspan="1" class="confluenceTd"><span style="color: rgb(0,0,0);">Specifies
whether multiple consumers are allowed. If enabled, y
ou can use Disruptor</span><span style="color:
rgb(0,0,0);"> for </span><a shape="rect" class="external-link"
href="http://en.wikipedia.org/wiki/Publish%E2%80%93subscribe_pattern";
rel="nofollow">Publish-Subscribe</a><span style="color:
rgb(0,0,0);"> messaging. That is, you can send a message to the SEDA queue
and have each consumer receive a copy of the message. When enabled, this option
should be specified on every consumer endpoint.</span></td></tr><tr><td
colspan="1" rowspan="1"
class="confluenceTd"><p>limitConcurrentConsumers</p></td><td colspan="1"
rowspan="1" class="confluenceTd"><p>true</p></td><td colspan="1" rowspan="1"
class="confluenceTd"><p>Whether to limit the number of concurrentConsumers to
the maximum of 500. By default, an exception will be thrown if a Disruptor
endpoint is configured with a greater number. You can disable that check by
turning this option off.</p></td></tr><tr><td colspan="1" rowspan="1"
class="confluenceTd"><p>blockWhenFull</p>
</td><td colspan="1" rowspan="1" class="confluenceTd"><p>true</p></td><td
colspan="1" rowspan="1" class="confluenceTd"><p>Whether a thread that sends
messages to a full Disruptor will block until the ringbuffer's capacity is no
longer exhausted. By default, the calling thread will block and wait until the
message can be accepted. By disabling this option, an exception will be thrown
stating that the queue is full.</p></td></tr><tr><td colspan="1" rowspan="1"
class="confluenceTd"><p>defaultBlockWhenFull</p></td><td colspan="1"
rowspan="1" class="confluenceTd"><p> </p></td><td colspan="1" rowspan="1"
class="confluenceTd"><p><strong>Component only:</strong> Allows to set the
default producer behaviour when the ringbuffer is full for endpoints created by
this comonent used when <em>blockWhenFull</em> is not
provided.</p></td></tr><tr><td colspan="1" rowspan="1"
class="confluenceTd"><p>waitStrategy</p></td><td colspan="1" rowspan="1"
class="confluenceTd"><p>Blocking</p></td><td cols
pan="1" rowspan="1" class="confluenceTd"><p>Defines the strategy used by
consumer threads to wait on new exchanges to be published. The options allowed
are:<em>Blocking</em>, <em>Sleeping</em>, <em>BusySpin</em> and
<em>Yielding</em>. Refer to the section below for more information on this
subject</p></td></tr><tr><td colspan="1" rowspan="1"
class="confluenceTd"><p>defaultWaitStrategy</p></td><td colspan="1" rowspan="1"
class="confluenceTd"><p> </p></td><td colspan="1" rowspan="1"
class="confluenceTd"><p><strong>Component only:</strong> Allows to set the
default wait strategy for endpoints created by this comonent used when
<em>waitStrategy</em> is not provided.</p></td></tr><tr><td colspan="1"
rowspan="1" class="confluenceTd"><p>producerType</p></td><td colspan="1"
rowspan="1" class="confluenceTd"><p>Multi</p></td><td colspan="1" rowspan="1"
class="confluenceTd"><p>Defines the producers allowed on the Disruptor. The
options allowed are: <em>Multi</em> to allow multiple produce
rs and <em>Single</em> to enable certain optimizations only allowed when one
concurrent producer (on one thread or otherwise synchronized) is
active.</p></td></tr><tr><td colspan="1" rowspan="1"
class="confluenceTd"><p>defaultProducerType</p></td><td colspan="1" rowspan="1"
class="confluenceTd"><p> </p></td><td colspan="1" rowspan="1"
class="confluenceTd"><p><strong>Component only:</strong> Allows to set the
default producer type for endpoints created by this comonent used when
<em>producerType</em> is not provided.</p></td></tr></tbody></table></div><h3
id="Disruptor-Waitstrategies">Wait strategies</h3><p>The wait strategy effects
the type of waiting performed by the consumer threads that are currently
waiting for the next exchange to be published. The following strategies can be
chosen:</p><div class="table-wrap"><table
class="confluenceTable"><tbody><tr><th colspan="1" rowspan="1"
class="confluenceTh"><p>Name</p></th><th colspan="1" rowspan="1"
class="confluenceTh"><p>Descri
ption</p></th><th colspan="1" rowspan="1"
class="confluenceTh"><p>Advice</p></th></tr><tr><td colspan="1" rowspan="1"
class="confluenceTd"><p>Blocking</p></td><td colspan="1" rowspan="1"
class="confluenceTd"><p>Blocking strategy that uses a lock and condition
variable for Consumers waiting on a barrier.</p></td><td colspan="1"
rowspan="1" class="confluenceTd"><p>This strategy can be used when throughput
and low-latency are not as important as CPU resource.</p></td></tr><tr><td
colspan="1" rowspan="1" class="confluenceTd"><p>Sleeping</p></td><td
colspan="1" rowspan="1" class="confluenceTd"><p>Sleeping strategy that
initially spins, then uses a Thread.yield(), and eventually for the minimum
number of nanos the OS and JVM will allow while the Consumers are waiting on a
barrier.</p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>This
strategy is a good compromise between performance and CPU resource. Latency
spikes can occur after quiet periods.</p></td></tr><tr><td colspan="1"
rowspan="1" class="confluenceTd"><p>BusySpin</p></td><td colspan="1"
rowspan="1" class="confluenceTd"><p>Busy Spin strategy that uses a busy spin
loop for Consumers waiting on a barrier.</p></td><td colspan="1" rowspan="1"
class="confluenceTd"><p>This strategy will use CPU resource to avoid syscalls
which can introduce latency jitter. It is best used when threads can be bound
to specific CPU cores.</p></td></tr><tr><td colspan="1" rowspan="1"
class="confluenceTd"><p>Yielding</p></td><td colspan="1" rowspan="1"
class="confluenceTd"><p>Yielding strategy that uses a Thread.yield() for
Consumers waiting on a barrier after an initially spinning.</p></td><td
colspan="1" rowspan="1" class="confluenceTd"><p>This strategy is a good
compromise between performance and CPU resource without incurring significant
latency spikes.</p></td></tr></tbody></table></div><h3
id="Disruptor-UseofRequestReply">Use of Request Reply</h3><p>The Disruptor
component supports using <a shape="rect" href="request-
reply.html">Request Reply</a>, where the caller will wait for the Async route
to complete. For instance:</p><div class="code panel pdl" style="border-width:
1px;"><div class="codeContent panelContent pdl">
+<script class="theme: Default; brush: java; gutter: false"
type="syntaxhighlighter"><![CDATA[from("mina:tcp://0.0.0.0:9876?textline=true&sync=true").to("disruptor:input");
from("disruptor:input").to("bean:processInput").to("bean:createResponse");
]]></script>
-</div></div>
-
-<p>In the route above, we have a TCP listener on port 9876 that accepts
incoming requests. The request is routed to the <em>disruptor:input</em>
buffer. As it is a <a shape="rect" href="request-reply.html">Request Reply</a>
message, we wait for the response. When the consumer on the
<em>disruptor:input</em> buffer is complete, it copies the response to the
original message response.</p>
-
-<h3 id="Disruptor-Concurrentconsumers">Concurrent consumers</h3>
-
-<p>By default, the Disruptor endpoint uses a single consumer thread, but you
can configure it to use concurrent consumer threads. So instead of thread pools
you can use:</p>
-<div class="code panel pdl" style="border-width: 1px;"><div class="codeContent
panelContent pdl">
-<script class="theme: Default; brush: java; gutter: false"
type="syntaxhighlighter"><![CDATA[
-from("disruptor:stageName?concurrentConsumers=5").process(...)
-]]></script>
-</div></div>
-<p>As for the difference between the two, note a thread pool can
increase/shrink dynamically at runtime depending on load, whereas the number of
concurrent consumers is always fixed and supported by the Disruptor internally
so performance will be higher.</p>
-
-<h3 id="Disruptor-Threadpools">Thread pools</h3>
-<p>Be aware that adding a thread pool to a Disruptor endpoint by doing
something like:</p>
-<div class="code panel pdl" style="border-width: 1px;"><div class="codeContent
panelContent pdl">
-<script class="theme: Default; brush: java; gutter: false"
type="syntaxhighlighter"><![CDATA[
-from("disruptor:stageName").thread(5).process(...)
-]]></script>
-</div></div>
-<p>Can wind up with adding a normal <a shape="rect" class="external-link"
href="http://docs.oracle.com/javase/1.5.0/docs/api/java/util/concurrent/BlockingQueue.html";
rel="nofollow">BlockingQueue</a> to be used in conjunction with the Disruptor,
effectively negating part of the performance gains achieved by using the
Disruptor. Instead, it is advices to directly configure number of threads that
process messages on a Disruptor endpoint using the concurrentConsumers
option.</p>
-
-<h3 id="Disruptor-Sample">Sample</h3>
-<p>In the route below we use the Disruptor to send the request to this async
queue to be able to send a fire-and-forget message for further processing in
another thread, and return a constant reply in this thread to the original
caller.</p>
-<div class="code panel pdl" style="border-width: 1px;"><div class="codeContent
panelContent pdl">
-<script class="theme: Default; brush: java; gutter: false"
type="syntaxhighlighter"><![CDATA[
-public void configure() throws Exception {
+</div></div><p>In the route above, we have a TCP listener on port 9876 that
accepts incoming requests. The request is routed to the
<em>disruptor:input</em> buffer. As it is a <a shape="rect"
href="request-reply.html">Request Reply</a> message, we wait for the response.
When the consumer on the <em>disruptor:input</em> buffer is complete, it copies
the response to the original message response.</p><h3
id="Disruptor-Concurrentconsumers">Concurrent consumers</h3><p>By default, the
Disruptor endpoint uses a single consumer thread, but you can configure it to
use concurrent consumer threads. So instead of thread pools you can
use:</p><div class="code panel pdl" style="border-width: 1px;"><div
class="codeContent panelContent pdl">
+<script class="theme: Default; brush: java; gutter: false"
type="syntaxhighlighter"><![CDATA[from("disruptor:stageName?concurrentConsumers=5").process(...)
+]]></script>
+</div></div><p>As for the difference between the two, note a thread pool can
increase/shrink dynamically at runtime depending on load, whereas the number of
concurrent consumers is always fixed and supported by the Disruptor internally
so performance will be higher.</p><h3 id="Disruptor-Threadpools">Thread
pools</h3><p>Be aware that adding a thread pool to a Disruptor endpoint by
doing something like:</p><div class="code panel pdl" style="border-width:
1px;"><div class="codeContent panelContent pdl">
+<script class="theme: Default; brush: java; gutter: false"
type="syntaxhighlighter"><![CDATA[from("disruptor:stageName").thread(5).process(...)
+]]></script>
+</div></div><p>Can wind up with adding a normal <a shape="rect"
class="external-link"
href="http://docs.oracle.com/javase/1.5.0/docs/api/java/util/concurrent/BlockingQueue.html";
rel="nofollow">BlockingQueue</a> to be used in conjunction with the Disruptor,
effectively negating part of the performance gains achieved by using the
Disruptor. Instead, it is advices to directly configure number of threads that
process messages on a Disruptor endpoint using the concurrentConsumers
option.</p><h3 id="Disruptor-Sample">Sample</h3><p>In the route below we use
the Disruptor to send the request to this async queue to be able to send a
fire-and-forget message for further processing in another thread, and return a
constant reply in this thread to the original caller.</p><div class="code panel
pdl" style="border-width: 1px;"><div class="codeContent panelContent pdl">
+<script class="theme: Default; brush: java; gutter: false"
type="syntaxhighlighter"><![CDATA[public void configure() throws Exception {
from("direct:start")
// send it to the disruptor that is async
.to("disruptor:next")
@@ -190,21 +122,12 @@ public void configure() throws Exception
from("disruptor:next").to("mock:result");
}
]]></script>
-</div></div>
-<p>Here we send a Hello World message and expects the reply to be OK.</p>
-<div class="code panel pdl" style="border-width: 1px;"><div class="codeContent
panelContent pdl">
-<script class="theme: Default; brush: java; gutter: false"
type="syntaxhighlighter"><![CDATA[
-Object out = template.requestBody("direct:start", "Hello
World");
+</div></div><p>Here we send a Hello World message and expects the reply to be
OK.</p><div class="code panel pdl" style="border-width: 1px;"><div
class="codeContent panelContent pdl">
+<script class="theme: Default; brush: java; gutter: false"
type="syntaxhighlighter"><![CDATA[Object out =
template.requestBody("direct:start", "Hello World");
assertEquals("OK", out);
]]></script>
-</div></div>
-<p>The "Hello World" message will be consumed from the Disruptor from another
thread for further processing. Since this is from a unit test, it will be sent
to a mock endpoint where we can do assertions in the unit test.</p>
-
-<h3 id="Disruptor-UsingmultipleConsumers">Using multipleConsumers</h3>
-<p>In this example we have defined two consumers and registered them as spring
beans.</p>
-<div class="code panel pdl" style="border-width: 1px;"><div class="codeContent
panelContent pdl">
-<script class="theme: Default; brush: java; gutter: false"
type="syntaxhighlighter"><![CDATA[
-<!-- define the consumers as spring beans -->
+</div></div><p>The "Hello World" message will be consumed from the Disruptor
from another thread for further processing. Since this is from a unit test, it
will be sent to a mock endpoint where we can do assertions in the unit
test.</p><h3 id="Disruptor-UsingmultipleConsumers">Using
multipleConsumers</h3><p>In this example we have defined two consumers and
registered them as spring beans.</p><div class="code panel pdl"
style="border-width: 1px;"><div class="codeContent panelContent pdl">
+<script class="theme: Default; brush: java; gutter: false"
type="syntaxhighlighter"><![CDATA[<!-- define the consumers as spring beans
-->
<bean id="consumer1"
class="org.apache.camel.spring.example.FooEventConsumer"/>
<bean id="consumer2"
class="org.apache.camel.spring.example.AnotherFooEventConsumer"/>
@@ -214,11 +137,8 @@ assertEquals("OK", out);
<endpoint id="foo"
uri="disruptor:foo?multipleConsumers=true"/>
</camelContext>
]]></script>
-</div></div>
-<p>Since we have specified multipleConsumers=true on the Disruptor foo
endpoint we can have those two or more consumers receive their own copy of the
message as a kind of pub-sub style messaging. As the beans are part of an unit
test they simply send the message to a mock endpoint, but notice how we can use
@Consume to consume from the Disruptor.</p>
-<div class="code panel pdl" style="border-width: 1px;"><div class="codeContent
panelContent pdl">
-<script class="theme: Default; brush: java; gutter: false"
type="syntaxhighlighter"><![CDATA[
-public class FooEventConsumer {
+</div></div><p>Since we have specified multipleConsumers=true on the Disruptor
foo endpoint we can have those two or more consumers receive their own copy of
the message as a kind of pub-sub style messaging. As the beans are part of an
unit test they simply send the message to a mock endpoint, but notice how we
can use @Consume to consume from the Disruptor.</p><div class="code panel pdl"
style="border-width: 1px;"><div class="codeContent panelContent pdl">
+<script class="theme: Default; brush: java; gutter: false"
type="syntaxhighlighter"><![CDATA[public class FooEventConsumer {
@EndpointInject(uri = "mock:result")
private ProducerTemplate destination;
@@ -230,17 +150,11 @@ public class FooEventConsumer {
}
]]></script>
-</div></div>
-
-<h3 id="Disruptor-Extractingdisruptorinformation">Extracting disruptor
information</h3>
-<p>If needed, information such as buffer size, etc. can be obtained without
using JMX in this fashion:</p>
-<div class="code panel pdl" style="border-width: 1px;"><div class="codeContent
panelContent pdl">
-<script class="theme: Default; brush: java; gutter: false"
type="syntaxhighlighter"><![CDATA[
-DisruptorEndpoint disruptor = context.getEndpoint("disruptor:xxxx");
+</div></div><h3 id="Disruptor-Extractingdisruptorinformation">Extracting
disruptor information</h3><p>If needed, information such as buffer size, etc.
can be obtained without using JMX in this fashion:</p><div class="code panel
pdl" style="border-width: 1px;"><div class="codeContent panelContent pdl">
+<script class="theme: Default; brush: java; gutter: false"
type="syntaxhighlighter"><![CDATA[DisruptorEndpoint disruptor =
context.getEndpoint("disruptor:xxxx");
int size = disruptor.getBufferSize();
]]></script>
-</div></div>
-</div>
+</div></div></div>
</td>
<td valign="top">
<div class="navigation">
