camel-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From conflue...@apache.org
Subject [CONF] Apache Camel > Disruptor
Date Mon, 03 Jun 2013 15:42:00 GMT
<html>
<head>
    <base href="https://cwiki.apache.org/confluence">
            <link rel="stylesheet" href="/confluence/s/2042/9/1/_/styles/combined.css?spaceKey=CAMEL&amp;forWysiwyg=true"
type="text/css">
    </head>
<body style="background: white;" bgcolor="white" class="email-body">
<div id="pageContent">
<div id="notificationFormat">
<div class="wiki-content">
<div class="email">
    <h2><a href="https://cwiki.apache.org/confluence/display/CAMEL/Disruptor">Disruptor</a></h2>
    <h4>Page  <b>added</b> by             <a href="https://cwiki.apache.org/confluence/display/~njiang">willem
jiang</a>
    </h4>
         <br/>
    <div class="notificationGreySide">
         <h2><a name="Disruptor-DisruptorComponent"></a>Disruptor Component</h2>

<p>The <b>disruptor:</b> component provides asynchronous <a href="http://www.eecs.harvard.edu/~mdw/proj/seda/"
class="external-link" rel="nofollow">SEDA</a> behavior much as the standard SEDA
Component, but utilizes a <a href="https://github.com/LMAX-Exchange/disruptor" class="external-link"
rel="nofollow">Disruptor</a> instead of a <a href="http://docs.oracle.com/javase/1.5.0/docs/api/java/util/concurrent/BlockingQueue.html"
class="external-link" rel="nofollow">BlockingQueue</a> utilized by the standard <a
href="/confluence/display/CAMEL/SEDA" title="SEDA">SEDA</a>. Alternatively, a</p>

<p><b>disruptor-vm:</b> endpoint is supported by this component, providing
an alternative to the standard <a href="/confluence/display/CAMEL/VM" title="VM">VM</a>.
As with the SEDA component, buffers of the <b>disruptor:</b> endpoints are only
visible within a <b>single</b> <a href="/confluence/display/CAMEL/CamelContext"
title="CamelContext">CamelContext</a> and no support is provided for persistence
or recovery. The buffers of the *<b>disruptor-vm:</b>* endpoints also provides
support for communication across CamelContexts instances so you can use this mechanism to
communicate across web applications (provided that <b>camel-disruptor.jar</b>
is on the <b>system/boot</b> 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 <b>pollTimeout</b> 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 <tt>pom.xml</tt>
for this component:</p>
<div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent">
<pre class="code-java">
&lt;dependency&gt;
    &lt;groupId&gt;org.apache.camel&lt;/groupId&gt;
    &lt;artifactId&gt;camel-cxf&lt;/artifactId&gt;
    &lt;version&gt;x.x.x&lt;/version&gt;
    &lt;!-- use the same version as your Camel core version --&gt;
&lt;/dependency&gt;
</pre>
</div></div>


<h3><a name="Disruptor-URIformat"></a>URI format</h3>
<div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent">
<pre class="code-java">
 disruptor:someName[?options]
</pre>
</div></div>
<p>or</p>
<div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent">
<pre class="code-java">
 disruptor-vm:someName[?options]
</pre>
</div></div>

<p>Where *<b>someName</b>* can be any string that uniquely identifies the
endpoint within the current <a href="/confluence/display/CAMEL/CamelContext" title="CamelContext">CamelContext</a>
(or across contexts in case of<br/>
*<b>disruptor-vm:</b>*).<br/>
You can append query options to the URI in the following format:</p>
<div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent">
<pre class="code-java">
  ?option=value&amp;option=value&amp;…
</pre>
</div></div>


<h3><a name="Disruptor-Options"></a>Options</h3>

<p>All the following options are valid for both the *<b>disruptor:</b>*
and *<b>disruptor-vm:</b>* components.</p>

<div class='table-wrap'>
<table class='confluenceTable'><tbody>
<tr>
<th class='confluenceTh'> <b>Name</b> </th>
<th class='confluenceTh'> <b>Default</b> </th>
<th class='confluenceTh'> <b>Description</b> </th>
</tr>
<tr>
<td class='confluenceTd'> size </td>
<td class='confluenceTd'> 1024 </td>
<td class='confluenceTd'>The maximum capacity of the Disruptors ringbuffer. Will be
effectively increased to the nearest power of two. <b>Notice:</b> 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.</td>
</tr>
<tr>
<td class='confluenceTd'> bufferSize </td>
<td class='confluenceTd'>&nbsp;</td>
<td class='confluenceTd'> <b>Component only:</b> 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.</td>
</tr>
<tr>
<td class='confluenceTd'> queueSize </td>
<td class='confluenceTd'>&nbsp;</td>
<td class='confluenceTd'> <b>Component only:</b> Additional option to specify
the &lt;em&gt;bufferSize&lt;/em&gt; to maintain maximum compatibility with
the <a href="/confluence/display/CAMEL/SEDA" title="SEDA">SEDA</a> Component.</td>
</tr>
<tr>
<td class='confluenceTd'> concurrentConsumers </td>
<td class='confluenceTd'> 1 </td>
<td class='confluenceTd'> Number of concurrent threads processing exchanges. </td>
</tr>
<tr>
<td class='confluenceTd'> waitForTaskToComplete </td>
<td class='confluenceTd'> IfReplyExpected </td>
<td class='confluenceTd'>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 href="/confluence/display/CAMEL/Request+Reply" title="Request Reply">Request
Reply</a> based. See more information about <a href="/confluence/display/CAMEL/Async"
title="Async">Async</a> messaging. </td>
</tr>
<tr>
<td class='confluenceTd'> timeout </td>
<td class='confluenceTd'> 30000 </td>
<td class='confluenceTd'> Timeout (in milliseconds) before a producer will stop waiting
for an asynchronous task to complete. See <em>waitForTaskToComplete</em> and <a
href="/confluence/display/CAMEL/Async" title="Async">Async</a> for more details.
You can disable timeout by using 0 or a negative value. </td>
</tr>
<tr>
<td class='confluenceTd'> defaultMultipleConsumers </td>
<td class='confluenceTd'>&nbsp;</td>
<td class='confluenceTd'> <b>Component only:</b> Allows to set the default
allowance of multiple consumers for endpoints created by this comonent used when <em>multipleConsumers</em>
is not provided.</td>
</tr>
<tr>
<td class='confluenceTd'> limitConcurrentConsumers </td>
<td class='confluenceTd'> true </td>
<td class='confluenceTd'> 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. </td>
</tr>
<tr>
<td class='confluenceTd'> blockWhenFull </td>
<td class='confluenceTd'> true </td>
<td class='confluenceTd'> 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.</td>
</tr>
<tr>
<td class='confluenceTd'> defaultBlockWhenFull </td>
<td class='confluenceTd'>&nbsp;</td>
<td class='confluenceTd'> <b>Component only:</b> 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. </td>
</tr>
<tr>
<td class='confluenceTd'> waitStrategy </td>
<td class='confluenceTd'> Blocking </td>
<td class='confluenceTd'> 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 </td>
</tr>
<tr>
<td class='confluenceTd'>defaultWaitStrategy</td>
<td class='confluenceTd'>&nbsp;</td>
<td class='confluenceTd'> <b>Component only:</b> Allows to set the default
wait strategy for endpoints created by this comonent used when <em>waitStrategy</em>
is not provided.</td>
</tr>
<tr>
<td class='confluenceTd'> producerType </td>
<td class='confluenceTd'> Multi </td>
<td class='confluenceTd'> 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.</td>
</tr>
<tr>
<td class='confluenceTd'>defaultProducerType</td>
<td class='confluenceTd'>&nbsp;</td>
<td class='confluenceTd'><b>Component only:</b> Allows to set the default
producer type for endpoints created by this comonent used when <em>producerType</em>
is not provided.</td>
</tr>
</tbody></table>
</div>


<h3><a name="Disruptor-Waitstrategies"></a>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 class='confluenceTh'>Name </th>
<th class='confluenceTh'> Description </th>
<th class='confluenceTh'> Advice </th>
</tr>
<tr>
<td class='confluenceTd'> Blocking </td>
<td class='confluenceTd'> Blocking strategy that uses a lock and condition variable
for Consumers waiting on a barrier.	</td>
<td class='confluenceTd'>This strategy can be used when throughput and low-latency are
not as important as CPU resource.</td>
</tr>
<tr>
<td class='confluenceTd'> Sleeping </td>
<td class='confluenceTd'> 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. </td>
<td class='confluenceTd'> This strategy is a good compromise between performance and
CPU resource. Latency spikes can occur after quiet periods. </td>
</tr>
<tr>
<td class='confluenceTd'> BusySpin </td>
<td class='confluenceTd'> Busy Spin strategy that uses a busy spin loop for Consumers
waiting on a barrier. </td>
<td class='confluenceTd'> 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.
</td>
</tr>
<tr>
<td class='confluenceTd'> Yielding </td>
<td class='confluenceTd'> Yielding strategy that uses a Thread.yield() for Consumers
waiting on a barrier after an initially spinning. </td>
<td class='confluenceTd'> This strategy is a good compromise between performance and
CPU resource without incurring significant latency spikes. </td>
</tr>
</tbody></table>
</div>


<h3><a name="Disruptor-UseofRequestReply"></a>Use of Request Reply</h3>
<p>The Disruptor component supports using <a href="/confluence/display/CAMEL/Request+Reply"
title="Request Reply">Request Reply</a>, where the caller will wait for the Async
route to complete. For instance:</p>
<div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent">
<pre class="code-java">
from(<span class="code-quote">"mina:tcp:<span class="code-comment">//0.0.0.0:9876?textline=<span
class="code-keyword">true</span>&amp;sync=<span class="code-keyword">true</span>"</span>).to(<span
class="code-quote">"disruptor:input"</span>);
</span>from(<span class="code-quote">"disruptor:input"</span>).to(<span
class="code-quote">"bean:processInput"</span>).to(<span class="code-quote">"bean:createResponse"</span>);
</pre>
</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
href="/confluence/display/CAMEL/Request+Reply" title="Request Reply">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><a name="Disruptor-Concurrentconsumers"></a>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" style="border-width: 1px;"><div class="codeContent panelContent">
<pre class="code-java">
from(<span class="code-quote">"disruptor:stageName?concurrentConsumers=5"</span>).process(...)
</pre>
</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>







    </div>
    <div id="commentsSection" class="wiki-content pageSection">
       <div style="float: right;">
            <a href="https://cwiki.apache.org/confluence/users/viewnotifications.action"
class="grey">Change Notification Preferences</a>
       </div>
       <a href="https://cwiki.apache.org/confluence/display/CAMEL/Disruptor">View Online</a>
              |
       <a href="https://cwiki.apache.org/confluence/display/CAMEL/Disruptor?showComments=true&amp;showCommentArea=true#addcomment">Add
Comment</a>
           </div>
</div>
</div>
</div>
</div>
</body>
</html>

Mime
View raw message