camel-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From build...@apache.org
Subject svn commit: r1011645 [3/3] - in /websites/production/camel/content: book-component-appendix.html book-in-one-page.html cache/main.pageCache disruptor.html seda.html
Date Thu, 04 May 2017 22:20:53 GMT
Modified: websites/production/camel/content/disruptor.html
==============================================================================
--- websites/production/camel/content/disruptor.html (original)
+++ websites/production/camel/content/disruptor.html Thu May  4 22:20:53 2017
@@ -40,6 +40,7 @@
   <link href='//camel.apache.org/styles/highlighter/styles/shThemeCamel.css' rel='stylesheet' type='text/css' />
   <script src='//camel.apache.org/styles/highlighter/scripts/shCore.js' type='text/javascript'></script>
   <script src='//camel.apache.org/styles/highlighter/scripts/shBrushJava.js' type='text/javascript'></script>
+  <script src='//camel.apache.org/styles/highlighter/scripts/shBrushXml.js' type='text/javascript'></script>
   
   <script type="text/javascript">
   SyntaxHighlighter.defaults['toolbar'] = false;
@@ -84,34 +85,41 @@
 	<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="brush: java; gutter: false; theme: Default" type="syntaxhighlighter"><![CDATA[&lt;dependency&gt;
+<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>.</p><p>Alternatively, a&#160;<strong><code>disruptor-vm:</code></strong> endpoint is supported by this component, providing an alternative to the standard <a shape="rect" href="vm.html">VM</a>.</p><p>As with the SEDA component, buffers of the <st
 rong><code>disruptor:</code></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 <strong><code>disruptor-vm:</code></strong> endpoints provides support for communication across CamelContexts instances (provided <strong><code>camel-disruptor.jar</code></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 mimicking the behavior and options of the SEDA and VM Components as much as possibl
 e. The main differences with include:</p><ul><li>The buffer used is always bounded in size (default&#160;<strong><code>1024</code></strong> exchanges).</li><li>As a the buffer is always bounded, the default behavior for the Disruptor is to block while the buffer is full instead of throwing an exception. This default behavior may be configured on the component (see options).</li><li>Disruptor endpoints don't implement the&#160;<strong><code>BrowsableEndpoint</code></strong> interface. As such, the exchanges currently in the Disruptor can't be retrieved, only the number of exchanges.</li><li>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 receive new exchanges published after they joined
 .</li><li>The <strong><code>pollTimeout</code></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 <strong><code>pom.xml</code></strong> for this component:</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;dependency&gt;
     &lt;groupId&gt;org.apache.camel&lt;/groupId&gt;
     &lt;artifactId&gt;camel-disruptor&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;
 ]]></script>
-</div></div><h3 id="Disruptor-URIformat">URI format</h3><div class="code panel pdl" style="border-width: 1px;"><div class="codeContent panelContent pdl">
+</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="brush: java; gutter: false; theme: Default" 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="brush: java; gutter: false; theme: Default" 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="brush: java; gutter: false; theme: Default" type="syntaxhighlighter"><![CDATA[  ?option=value&amp;option=value&amp;…
+</div></div><p>Where&#160;<strong><code>someName</code></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 <strong><code>disruptor-vm:</code></strong>).</p><p>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="brush: java; gutter: false; theme: Default" type="syntaxhighlighter"><![CDATA[?option=value&amp;option=value&amp;...
 ]]></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 colspan="1" rowspan="1" class="confluenceTd"><p>&#160;</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>&#160;</p></td><td colspan="1" rowspan="1" class="confluenceTd"><p><strong>Component only:</strong> Additional option to specify the &lt;em&gt;bufferSize&lt;/em&gt; 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>&#160;</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&#160;Disruptor</span><span style="color: rgb(0,0,0);">&#160;for&#160;</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);">&#160;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>&#160;</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>&#160;</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>&#160;</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="brush: java; gutter: false; theme: Default" type="syntaxhighlighter"><![CDATA[from(&quot;mina:tcp://0.0.0.0:9876?textline=true&amp;sync=true&quot;).to(&quot;disruptor:input&quot;);
-from(&quot;disruptor:input&quot;).to(&quot;bean:processInput&quot;).to(&quot;bean:createResponse&quot;);
+</div></div><h3 id="Disruptor-Options">Options</h3><p>All the following options are valid for both the&#160;<strong><code>disruptor:</code></strong> and&#160;<strong><code>disruptor-vm:</code></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><code>size</code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p><code>1024</code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>The maximum capacity of the Disruptors ring buffer. Will be effectively increased to the nearest power of two. </p><div class="confluence-information-macro confluence-information-macro-warning"><span class="aui-icon aui-icon-small aui-iconfo
 nt-error confluence-information-macro-icon"></span><div class="confluence-information-macro-body"><strong>Note:</strong> Care should be taken when using this option. The size is determined by the value specified <em>when the first endpoint is created</em>. Each endpoint must therefore specify the same size.</div></div></td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><p><code>bufferSize</code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>&#160;</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 ring buffer. This option is used if size is not in use.</p></td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><p><code>queueSize</code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>&#160;</p></td><td colspan="1" rowspan="1" class="confluenceTd"><p><strong>Component only:</strong> Additional option to specif
 y the&#160;<strong><code>bufferSize</code></strong> 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><code>concurrentConsumers</code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p><code>1</code></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><code>waitForTaskToComplete</code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p><code>IfReplyExpected</code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>Option to specify whether the caller should wait for the asynchronous task to complete before continuing.</p><p>The following options are supported:</p><ul><li><p><strong><code>Always</code></strong></p></li><li><p><strong><code>Never</code></strong></p></li><li><p><strong><code>IfReplyExpected</code></stro
 ng></p></li></ul><p>The first two values are self-explanatory.</p><p>The last value, <strong><code>IfReplyExpected</code></strong>, will only wait if the message is <a shape="rect" href="https://cwiki.apache.org/confluence/display/CAMEL/Request+Reply">Request Reply</a> based.</p><p>See <a shape="rect" href="https://cwiki.apache.org/confluence/display/CAMEL/Async">Async</a> messaging for more details.</p></td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><p><code>timeout</code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p><code>30000</code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>Timeout (in milliseconds) before a&#160;<strong>seda</strong> producer will stop waiting for an asynchronous task to complete.</p><p>See <strong><code>waitForTaskToComplete</code></strong> and <a shape="rect" href="https://cwiki.apache.org/confluence/display/CAMEL/Async">Async</a> for more details.</p><p>Disable the&#160;<strong><code>timeout</code></strong> by 
 using&#160;<strong><code>0</code></strong> or a negative value.</p></td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><p><code>defaultMultipleConsumers</code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>&#160;</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 <strong><code>multipleConsumers</code></strong> is not provided.</p></td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><code>multipleConsumers</code></td><td colspan="1" rowspan="1" class="confluenceTd"><code>false</code></td><td colspan="1" rowspan="1" class="confluenceTd"><p><span style="color: rgb(0,0,0);">Specifies whether multiple consumers are allowed. If <strong><code>true</code></strong>, you can use&#160;Disruptor</span><span style="color: rgb(0,0,0);">&#160;for&#160;</span><a shape="rect" class="external-link" href="http://en.wiki
 pedia.org/wiki/Publish%E2%80%93subscribe_pattern" rel="nofollow">Publish-Subscribe</a><span style="color: rgb(0,0,0);">&#160;messaging. That is, you can send a message to the SEDA queue and have each consumer receive a copy of the message. </span></p><div class="confluence-information-macro confluence-information-macro-information"><span class="aui-icon aui-icon-small aui-iconfont-info confluence-information-macro-icon"></span><div class="confluence-information-macro-body">When&#160;<strong><code>true</code></strong>, this option should be specified on <em>every</em> consumer endpoint.</div></div></td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><p><code>limitConcurrentConsumers</code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p><code>true</code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>Whether to limit the number of <strong><code>concurrentConsumer</code></strong>'s to the maximum of <strong><code>500</code></strong>.</p><p>By default
 , an exception will be thrown if a Disruptor endpoint is configured with a greater number.</p><p>When&#160;<strong><code>false</code></strong> the number of concurrent consumers is unlimited.</p></td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><p><code>blockWhenFull</code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p><code>true</code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>Whether a thread that sends messages to a full Disruptor will block until the ring buffer's capacity is no longer exhausted.</p><p>By default, the calling thread will block and wait until the message can be accepted.</p><p>When&#160;<strong><code>false</code></strong> an exception will be thrown stating that the queue is full.</p></td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><p><code>defaultBlockWhenFull</code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>&#160;</p></td><td colspan="1" rowspan="1" class="confluenceTd"><p><strong>Comp
 onent only:</strong> configures the producer's default behavior when the ring buffer is full for endpoints created by this component.</p><p>This option is ignored when <strong><code>blockWhenFull=true</code></strong>.</p></td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><p><code>waitStrategy</code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p><code>Blocking</code></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.</p><p>The following options are supported:<br clear="none"><em> </em></p><ul><li><strong><code>Blocking</code></strong></li><li><strong><code>Sleeping</code></strong></li><li><strong><code>BusySpin</code></strong></li><li><strong> <code>Yielding</code></strong></li></ul><p>Refer to the section below for more information on this subject</p></td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><p><code>defaultWaitStrategy</code></p></td><td co
 lspan="1" rowspan="1" class="confluenceTd"><p>&#160;</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 component used when&#160;<strong><code>waitStrategy</code></strong> is not provided.</p></td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><p><code>producerType</code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p><code>Multi</code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>Defines the producers allowed on the Disruptor.</p><p>The following options are supported:<br clear="none"></p><ul><li><strong><code>Multi</code></strong> - allow multiple producers</li><li><strong> <code>Single</code></strong> - enable certain optimizations only allowed when one concurrent producer (on one thread or otherwise synchronized) is active.</li></ul></td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><p><code>defaultProducerType</code><
 /p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>&#160;</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 component used when&#160;<strong><code>producerType</code></strong> 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><strong><code>Blocking</code></strong></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><strong><code>Sleeping</code></strong></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>Sleeping strategy that initially spins, then uses a <strong><code>Thread.yield()</code></strong>, 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><strong><code>BusySpin</code></strong></p></td><td colspan="1" rowspan="1" class="con
 fluenceTd"><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><strong><code>Yielding</code></strong></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>Yielding strategy that uses a&#160;<strong><code>Thread.yield()</code></strong> 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="brush: java; gutter: false; theme: Default" type="syntaxhighlighter"><![CDATA[from(&quot;mina:tcp://0.0.0.0:9876?textline=true&amp;sync=true&quot;)
+  .to(&quot;disruptor:input&quot;);
+
+from(&quot;disruptor:input&quot;)
+  .to(&quot;bean:processInput&quot;)
+  .to(&quot;bean:createResponse&quot;);
+]]></script>
+</div></div><p>In the route above, we have a TCP listener on port&#160;<strong><code>9876</code></strong> that accepts incoming requests. The request is routed to the <strong><code>disruptor:input</code></strong> 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&#160;<strong><code>disruptor:input</code></strong> 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="brush: java; gutter: false; theme: Default" type="syntaxhighlighter"><![CDATA[from(&quot;disruptor:stageName?concurrentConsumers=5&quot;)
+  .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">Threadpools</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="brush: java; gutter: false; theme: Default" type="syntaxhighlighter"><![CDATA[from(&quot;disruptor:stageName&quot;)
+  .thread(5)
+  .process(...)
 ]]></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="brush: java; gutter: false; theme: Default" type="syntaxhighlighter"><![CDATA[from(&quot;disruptor:stageName?concurrentConsumers=5&quot;).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="brush: java; gutter: false; theme: Default" type="syntaxhighlighter"><![CDATA[from(&quot;disruptor:stageName&quot;).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">
+</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's recommended to directly configure the number of threads that process messages on a Disruptor endpoint using the&#160;<strong><code>concurrentConsumers</code></strong> option.</p><h3 id="Disruptor-Sample">Sample</h3><p>In the route below we use the Disruptor to send the request to this asynchronous 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="brush: java; gutter: false; theme: Default" type="syntaxhighlighter"><![CDATA[public void configure() throws Exception {
     from(&quot;direct:start&quot;)
         // send it to the disruptor that is async
@@ -119,15 +127,16 @@ from(&quot;disruptor:input&quot;).to(&qu
         // return a constant response
         .transform(constant(&quot;OK&quot;));
 
-    from(&quot;disruptor:next&quot;).to(&quot;mock:result&quot;);
+    from(&quot;disruptor:next&quot;)
+      .to(&quot;mock:result&quot;);
 }
 ]]></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">
+</div></div><p>Here we send a&#160;<strong><code>Hello World</code></strong> message and expects the reply to be <strong><code>OK</code></strong>.</p><div class="code panel pdl" style="border-width: 1px;"><div class="codeContent panelContent pdl">
 <script class="brush: java; gutter: false; theme: Default" type="syntaxhighlighter"><![CDATA[Object out = template.requestBody(&quot;direct:start&quot;, &quot;Hello World&quot;);
 assertEquals(&quot;OK&quot;, 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="brush: java; gutter: false; theme: Default" type="syntaxhighlighter"><![CDATA[&lt;!-- define the consumers as spring beans --&gt;
+</div></div><p>The&#160;<strong><code>Hello World</code></strong> 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&#160;<strong><code>mock</code></strong> endpoint where we can do assertions in the unit test.</p><h3 id="Disruptor-UsingmultipleConsumers">Using&#160;<code>multipleConsumers</code></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="brush: xml; gutter: false; theme: Default" type="syntaxhighlighter"><![CDATA[&lt;!-- define the consumers as spring beans --&gt;
 &lt;bean id=&quot;consumer1&quot; class=&quot;org.apache.camel.spring.example.FooEventConsumer&quot;/&gt;
 
 &lt;bean id=&quot;consumer2&quot; class=&quot;org.apache.camel.spring.example.AnotherFooEventConsumer&quot;/&gt;
@@ -137,7 +146,7 @@ assertEquals(&quot;OK&quot;, out);
     &lt;endpoint id=&quot;foo&quot; uri=&quot;disruptor:foo?multipleConsumers=true&quot;/&gt;
 &lt;/camelContext&gt;
 ]]></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">
+</div></div><p>Since we have specified&#160;<strong><code>multipleConsumers=true</code></strong> on the Disruptor&#160;<strong><code>foo</code></strong> 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&#160;<strong><code>mock</code></strong> endpoint.</p><p>Note the use of <strong><code>@Consume</code></strong> to consume from the Disruptor.</p><div class="code panel pdl" style="border-width: 1px;"><div class="codeContent panelContent pdl">
 <script class="brush: java; gutter: false; theme: Default" type="syntaxhighlighter"><![CDATA[public class FooEventConsumer {
 
     @EndpointInject(uri = &quot;mock:result&quot;)
@@ -150,7 +159,7 @@ assertEquals(&quot;OK&quot;, out);
 
 }
 ]]></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">
+</div></div><h3 id="Disruptor-ExtractingdisruptorInformation">Extracting&#160;<code>disruptor</code> 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="brush: java; gutter: false; theme: Default" type="syntaxhighlighter"><![CDATA[DisruptorEndpoint disruptor = context.getEndpoint(&quot;disruptor:xxxx&quot;);
 int size = disruptor.getBufferSize();
 ]]></script>

Modified: websites/production/camel/content/seda.html
==============================================================================
--- websites/production/camel/content/seda.html (original)
+++ websites/production/camel/content/seda.html Thu May  4 22:20:53 2017
@@ -86,41 +86,53 @@
 	<tbody>
         <tr>
         <td valign="top" width="100%">
-<div class="wiki-content maincontent"><h2 id="SEDA-SEDAComponent">SEDA Component</h2><p>The <strong>seda:</strong> component provides asynchronous <a shape="rect" class="external-link" href="http://www.eecs.harvard.edu/~mdw/proj/seda/" rel="nofollow">SEDA</a> behavior, so that messages are exchanged on a <a shape="rect" class="external-link" href="http://java.sun.com/j2se/1.5.0/docs/api/java/util/concurrent/BlockingQueue.html" rel="nofollow">BlockingQueue</a> and consumers are invoked in a separate thread from the producer.</p><p>Note that queues are only visible within a <em>single</em> <a shape="rect" href="camelcontext.html">CamelContext</a>. If you want to communicate across <code>CamelContext</code> instances (for example, communicating between Web applications), see the <a shape="rect" href="vm.html">VM</a> component.</p><p>This component does not implement any kind of persistence or recovery, if the VM terminates while messages are yet to be processed. If you need persistence
 , reliability or distributed SEDA, try using either <a shape="rect" href="jms.html">JMS</a> or <a shape="rect" href="activemq.html">ActiveMQ</a>.</p><div class="confluence-information-macro confluence-information-macro-tip"><p class="title">Synchronous</p><span class="aui-icon aui-icon-small aui-iconfont-approve confluence-information-macro-icon"></span><div class="confluence-information-macro-body"><p>The <a shape="rect" href="direct.html">Direct</a> component provides synchronous invocation of any consumers when a producer sends a message exchange.</p></div></div><h3 id="SEDA-URIformat">URI format</h3><div class="code panel pdl" style="border-width: 1px;"><div class="codeContent panelContent pdl">
+<div class="wiki-content maincontent"><h2 id="SEDA-SEDAComponent">SEDA Component</h2><p>The <strong><code>seda:</code></strong> component provides asynchronous <a shape="rect" class="external-link" href="http://www.eecs.harvard.edu/~mdw/proj/seda/" rel="nofollow">SEDA</a> behavior, so that messages are exchanged on a <a shape="rect" class="external-link" href="http://java.sun.com/j2se/1.5.0/docs/api/java/util/concurrent/BlockingQueue.html" rel="nofollow">BlockingQueue</a> and consumers are invoked in a separate thread from the producer.</p><p>Note that queues are only visible within a <em>single</em> <a shape="rect" href="camelcontext.html">CamelContext</a>. If you want to communicate across <strong><code>CamelContext</code></strong> instances (for example, communicating between Web applications), see the <a shape="rect" href="vm.html">VM</a> component.</p><p>This component does not implement any kind of persistence or recovery, if the VM terminates while messages are yet to be proc
 essed. If you need persistence, reliability or distributed SEDA, try using either <a shape="rect" href="jms.html">JMS</a> or <a shape="rect" href="activemq.html">ActiveMQ</a>.</p><div class="confluence-information-macro confluence-information-macro-tip"><p class="title">Synchronous</p><span class="aui-icon aui-icon-small aui-iconfont-approve confluence-information-macro-icon"></span><div class="confluence-information-macro-body"><p>The <a shape="rect" href="direct.html">Direct</a> component provides synchronous invocation of any consumers when a producer sends a message exchange.</p></div></div><h3 id="SEDA-URIformat">URI format</h3><div class="code panel pdl" style="border-width: 1px;"><div class="codeContent panelContent pdl">
 <script class="brush: java; gutter: false; theme: Default" type="syntaxhighlighter"><![CDATA[seda: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>.</p><p>You can append query options to the URI in the following format: <code>?option=value&amp;option=value&amp;&#8230;</code></p><h3 id="SEDA-Options">Options</h3><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>Since</p></th><th colspan="1" rowspan="1" class="confluenceTh"><p>Default</p></th><th colspan="1" rowspan="1" class="confluenceTh"><p>Description</p></th></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><p><code>size</code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>&#160;</p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>&#160;</p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>The maximum capacity of the SEDA queue (i.
 e., the number of messages it can hold). The default value in Camel 2.2 or older is <code>1000</code>. From Camel 2.3 onwards, the size is unbounded by default. <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. From <strong>Camel 2.11</strong> onwards, a validation is taken place to ensure if using mixed queue sizes for the same queue name, Camel would detect this and fail creating the endpoint.</p></td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><p><code>concurrentConsumers</code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>&#160;</p></td><td colspan="1" rowspan="1" class="confluenceTd"><p><code>1</code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>Number of concurrent threads processing exchanges.</p></td></tr><tr><td col
 span="1" rowspan="1" class="confluenceTd"><p><code>waitForTaskToComplete</code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>&#160;</p></td><td colspan="1" rowspan="1" class="confluenceTd"><p><code>IfReplyExpected</code></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: <code>Always</code>, <code>Never</code> or <code>IfReplyExpected</code>. The first two values are self-explanatory. The last value, <code>IfReplyExpected</code>, will only wait if the message is <a shape="rect" href="request-reply.html">Request Reply</a> based. The default option is <code>IfReplyExpected</code>. 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><code>timeout</code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>&#160;
 </p></td><td colspan="1" rowspan="1" class="confluenceTd"><p><code>30000</code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>Timeout (in milliseconds) before a SEDA producer will stop waiting for an asynchronous task to complete. See <code>waitForTaskToComplete</code> and <a shape="rect" href="async.html">Async</a> for more details. In <strong>Camel 2.2</strong> you can now disable timeout by using 0 or a negative value.</p></td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><p><code>multipleConsumers</code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p><strong>2.2</strong></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p><code>false</code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>Specifies whether multiple consumers are allowed. If enabled, you can use <a shape="rect" href="seda.html">SEDA</a> for <a shape="rect" class="external-link" href="http://en.wikipedia.org/wiki/Publish%E2%80%93subscribe_pattern" rel="nofo
 llow">Publish-Subscribe</a> 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.</p></td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><p><code>limitConcurrentConsumers</code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p><strong>2.3</strong></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p><code>true</code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>Whether to limit the number of <code>concurrentConsumers</code> to the maximum of <code>500</code>. By default, an exception will be thrown if a SEDA 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><code>blockWhenFull</code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p><strong>2.9</strong></p></td><td colspan="1" ro
 wspan="1" class="confluenceTd"><p><code>false</code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>Whether a thread that sends messages to a full SEDA queue will block until the queue's capacity is no longer exhausted. By default, an exception will be thrown stating that the queue is full. By enabling this option, the calling thread will instead block and wait until the message can be accepted.</p></td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><p><code>queueSize</code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p><strong>2.9</strong></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>&#160;</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 SEDA queue. This option is used if <code>size</code> is not in use.</p></td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><p><code>pollTimeout</code></p></td><
 td colspan="1" rowspan="1" class="confluenceTd"><p><strong>2.9.3</strong></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p><code>1000</code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p><em>Consumer only</em> &#8211; The timeout used when polling. When a timeout occurs, the consumer can check whether it is allowed to continue running. Setting a lower value allows the consumer to react more quickly upon shutdown.</p></td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><p><code>purgeWhenStopping</code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p><strong>2.11.1</strong></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p><code>false</code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>Whether to purge the task queue when stopping the consumer/route. This allows to stop faster, as any pending messages on the queue is discarded.</p></td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><p><code>queue</code>
 </p></td><td colspan="1" rowspan="1" class="confluenceTd"><p><strong>2.12.0</strong></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>null</p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>Define the queue instance which will be used by seda endpoint</p></td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><p><code>queueFactory</code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p><strong>2.12.0</strong></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>null</p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>Define the QueueFactory which could create the queue for the seda endpoint</p></td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><p><code>failIfNoConsumers</code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p><strong>2.12.0</strong></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>false</p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>Whether the producer should fail by 
 throwing an exception, when sending to a SEDA queue with no active consumers.</p><p>Only one of the options discardIfNoConsumers and failIfNoConsumers can be enabled at the same time.</p></td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><code>discardIfNoConsumers</code></td><td colspan="1" rowspan="1" class="confluenceTd"><strong>2.16</strong></td><td colspan="1" rowspan="1" class="confluenceTd"><code>false</code></td><td colspan="1" rowspan="1" class="confluenceTd"><p>Whether the producer should discard the message (do not add the message to the queue), when sending to a SEDA queue with no active consumers.</p><p><span>Only one of the options discardIfNoConsumers and failIfNoConsumers can be enabled at the same time.</span></p></td></tr></tbody></table></div><h3 id="SEDA-ChoosingBlockingQueueimplementation">Choosing BlockingQueue implementation</h3><p><strong>Available as of Camel 2.12</strong></p><p>By default, the SEDA component always intantiates LinkedBlockingQueue
 , but you can use different implementation, you can reference your own BlockingQueue implementation, in this case the size option is not used</p><div class="code panel pdl" style="border-width: 1px;"><div class="codeContent panelContent pdl">
-<script class="brush: java; gutter: false; theme: Default" type="syntaxhighlighter"><![CDATA[&lt;bean id=&quot;arrayQueue&quot; class=&quot;java.util.ArrayBlockingQueue&quot;&gt;
-&lt;constructor-arg index=&quot;0&quot; value=&quot;10&quot; &gt;&lt;!-- size --&gt;
-&lt;constructor-arg index=&quot;1&quot; value=&quot;true&quot; &gt;&lt;!-- fairness --&gt;
+</div></div><p>Where&#160;<strong><code>someName</code></strong> can be any string that uniquely identifies the endpoint within the current <a shape="rect" href="camelcontext.html">CamelContext</a>.</p><p>You can append query options to the URI in the following format: <strong><code>?option=value&amp;option=value&amp;...</code></strong></p><h3 id="SEDA-Options">Options</h3><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>Since</p></th><th colspan="1" rowspan="1" class="confluenceTh"><p>Default</p></th><th colspan="1" rowspan="1" class="confluenceTh"><p>Description</p></th></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><p><code>size</code></p></td><td colspan="1" rowspan="1" class="confluenceTd">&#160;</td><td colspan="1" rowspan="1" class="confluenceTd">&#160;</td><td colspan="1" rowspan="1" class="confluenceTd"><p>The maximum capacity of t
 he&#160;<strong>seda</strong> queue, i.e., the number of messages it can hold.</p><p>The default value in <strong>Camel 2.2</strong> or older is <strong><code>1000</code></strong>.</p><p>From <strong>Camel 2.3</strong>: the size is unbounded by default.</p><p>&#160;</p><div class="confluence-information-macro confluence-information-macro-warning"><span class="aui-icon aui-icon-small aui-iconfont-error confluence-information-macro-icon"></span><div class="confluence-information-macro-body"><p><strong>Note:</strong> Care should be taken when using this option. The size is determined by the value specified <em>when the first endpoint is created</em>. Each endpoint must therefore specify the same size.</p><p><strong>From</strong> <strong>Camel 2.11</strong>: a validation is taken place to ensure if using mixed queue sizes for the same queue name, Camel would detect this and fail creating the endpoint.</p></div></div></td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><p><code
 >concurrentConsumers</code></p></td><td colspan="1" rowspan="1" class="confluenceTd">&#160;</td><td colspan="1" rowspan="1" class="confluenceTd"><p><code>1</code></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><code>waitForTaskToComplete</code></p></td><td colspan="1" rowspan="1" class="confluenceTd">&#160;</td><td colspan="1" rowspan="1" class="confluenceTd"><p><code>IfReplyExpected</code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>Option to specify whether the caller should wait for the asynchronous task to complete before continuing.</p><p>The following options are supported:</p><ul><li><p><strong><code>Always</code></strong></p></li><li><p><strong><code>Never</code></strong></p></li><li><p><strong><code>IfReplyExpected</code></strong></p></li></ul><p>The first two values are self-explanatory.</p><p>The last value, <strong><code>IfR
 eplyExpected</code></strong>, will only wait if the message is <a shape="rect" href="request-reply.html">Request Reply</a> based.</p><p>See <a shape="rect" href="async.html">Async</a> messaging for more details.</p></td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><p><code>timeout</code></p></td><td colspan="1" rowspan="1" class="confluenceTd">&#160;</td><td colspan="1" rowspan="1" class="confluenceTd"><p><code>30000</code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>Timeout (in milliseconds) before a&#160;<strong>seda</strong> producer will stop waiting for an asynchronous task to complete.</p><p>See <strong><code>waitForTaskToComplete</code></strong> and <a shape="rect" href="async.html">Async</a> for more details.</p><p>From <strong>Camel 2.2:</strong> you can now disable timeout by using&#160;<strong><code>0</code></strong> or a negative value.</p></td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><p><code>multipleConsumers</code></p></td
 ><td colspan="1" rowspan="1" class="confluenceTd"><p><strong>2.2</strong></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p><code>false</code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>Specifies whether multiple consumers are allowed. If enabled, you can use <a shape="rect" href="seda.html">SEDA</a> for <a shape="rect" class="external-link" href="http://en.wikipedia.org/wiki/Publish%E2%80%93subscribe_pattern" rel="nofollow">Publish-Subscribe</a> messaging. That is, you can send a message to the&#160;<strong>seda</strong> queue and have each consumer receive a copy of the message. When enabled, this option should be specified on every consumer endpoint.</p></td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><p><code>limitConcurrentConsumers</code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p><strong>2.3</strong></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p><code>true</code></p></td><td colspan="1" rowspan="1" class=
 "confluenceTd"><p>Whether to limit the number of <strong><code>concurrentConsumers</code></strong> to the maximum of <strong><code>500</code></strong>.</p><p>By default, an exception will be thrown if a&#160;<strong>seda</strong> 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><code>blockWhenFull</code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p><strong>2.9</strong></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p><code>false</code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>Whether a thread that sends messages to a full&#160;<strong>seda</strong> queue will block until the queue's capacity is no longer exhausted. By default, an exception will be thrown stating that the queue is full. By enabling this option, the calling thread will instead block and wait until the message can be accepted.</p></td></tr><tr><td colspan=
 "1" rowspan="1" class="confluenceTd"><p><code>queueSize</code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p><strong>2.9</strong></p></td><td colspan="1" rowspan="1" class="confluenceTd">&#160;</td><td colspan="1" rowspan="1" class="confluenceTd"><p><strong>Component only:</strong> the maximum size (capacity of the number of messages it can hold) of the&#160;<strong>seda</strong> queue.</p><div class="confluence-information-macro confluence-information-macro-information"><span class="aui-icon aui-icon-small aui-iconfont-info confluence-information-macro-icon"></span><div class="confluence-information-macro-body">This option is used when <strong><code>size</code></strong> is not specified.</div></div></td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><p><code>pollTimeout</code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p><strong>2.9.3</strong></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p><code>1000</code></p></td><td colspan="1
 " rowspan="1" class="confluenceTd"><p><strong>Consumer only</strong>: the timeout used when polling. When a timeout occurs, the consumer can check whether it is allowed to continue running. Setting a lower value allows the consumer to react more quickly upon shutdown.</p></td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><p><code>purgeWhenStopping</code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p><strong>2.11.1</strong></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p><code>false</code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>Whether to purge the task queue when stopping the consumer/route. This allows to stop faster, as any pending messages on the queue is discarded.</p></td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><p><code>queue</code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p><strong>2.12.0</strong></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p><code>null</code></p></td><t
 d colspan="1" rowspan="1" class="confluenceTd"><p>Define the queue instance which will be used by <strong>seda</strong> endpoint</p></td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><p><code>queueFactory</code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p><strong>2.12.0</strong></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p><code>null</code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>Define the&#160;<strong><code>QueueFactory</code></strong> which could create the queue for the <strong>seda</strong> endpoint</p></td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><p><code>failIfNoConsumers</code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p><strong>2.12.0</strong></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p><code>false</code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>Whether the producer should fail by throwing an exception when sending to a&#160;<strong>seda</strong
 > queue with no active consumers.</p><div class="confluence-information-macro confluence-information-macro-information"><span class="aui-icon aui-icon-small aui-iconfont-info confluence-information-macro-icon"></span><div class="confluence-information-macro-body">Only one of the options&#160;<span><strong><code>discardIfNoConsumers</code></strong></span> and <span><strong><code>failIfNoConsumers</code></strong></span> can be enabled at the same time.</div></div></td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><p><code>discardIfNoConsumers</code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p><strong>2.16</strong></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p><code>false</code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>Whether the producer should discard the message (do not add the message to the queue) when sending to a&#160;<strong>seda</strong> queue with no active consumers.<span>&#160;</span></p><div class="confluence-in
 formation-macro confluence-information-macro-information"><span class="aui-icon aui-icon-small aui-iconfont-info confluence-information-macro-icon"></span><div class="confluence-information-macro-body">Only one of the options&#160;<strong><code>discardIfNoConsumers</code></strong> and&#160;<strong><code>failIfNoConsumers</code></strong> can be enabled at the same time.</div></div></td></tr></tbody></table></div><h3 id="SEDA-ChoosingBlockingQueueimplementation">Choosing BlockingQueue implementation</h3><p><strong>Available as of Camel 2.12</strong></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;bean id=&quot;arrayQueue&quot; class=&quot;java.util.ArrayBlockingQueue&quot;&gt;
+  &lt;constructor-arg index=&quot;0&quot; value=&quot;10&quot;&gt;   &lt;!-- size --&gt;
+  &lt;constructor-arg index=&quot;1&quot; value=&quot;true&quot;&gt; &lt;!-- fairness --&gt;
 &lt;/bean&gt;
-&lt;!-- ... and later --&gt;
-&lt;from&gt;seda:array?queue=#arrayQueue&lt;/from&gt;
+
+&lt;!-- ... --&gt;
+
+&lt;from uri=&quot;seda:array?queue=#arrayQueue&quot;/&gt;
 ]]></script>
-</div></div><p>Or you can reference a BlockingQueueFactory implementation, 3 implementations are provided LinkedBlockingQueueFactory, ArrayBlockingQueueFactory and PriorityBlockingQueueFactory:</p><div class="code panel pdl" style="border-width: 1px;"><div class="codeContent panelContent pdl">
-<script class="brush: java; gutter: false; theme: Default" type="syntaxhighlighter"><![CDATA[&lt;bean id=&quot;priorityQueueFactory&quot; class=&quot;org.apache.camel.component.seda.PriorityBlockingQueueFactory&quot;&gt;
-&lt;property name=&quot;comparator&quot;&gt;
-&lt;bean class=&quot;org.apache.camel.demo.MyExchangeComparator&quot; /&gt;
-&lt;/property&gt;
+</div></div><p>By default, the&#160;<strong>seda</strong> component instantiates a <strong><code>LinkedBlockingQueue</code></strong>. However, a different implementation can be chosen by specifying a custom&#160; <strong><code>BlockingQueue</code></strong> implementation. When a custom implementation is configured the&#160;<strong><code>size</code></strong> option is ignored.</p><p>The list of available&#160;<strong><code>BlockingQueueFactory</code></strong> implementations includes:</p><ul><li><strong><code>LinkedBlockingQueueFactory</code></strong></li><li><strong><code>ArrayBlockingQueueFactory</code></strong></li><li><strong><code>PriorityBlockingQueueFactory</code></strong><br clear="none"><br clear="none"></li></ul><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;bean id=&quot;priorityQueueFactory&quot; class=&quot;org.apache.camel.component.seda.PriorityBlockingQueueFactory&quot;&gt;
+  &lt;property name=&quot;comparator&quot;&gt;
+    &lt;bean class=&quot;org.apache.camel.demo.MyExchangeComparator&quot;/&gt;
+  &lt;/property&gt;
 &lt;/bean&gt;
-&lt;!-- ... and later --&gt;
-&lt;from&gt;seda:priority?queueFactory=#priorityQueueFactory&amp;size=100&lt;/from&gt;
-]]></script>
+
+&lt;!-- ...and later --&gt;
+
+&lt;from uri=&quot;seda:priority?queueFactory=#priorityQueueFactory&amp;size=100&quot;/&gt;
+&lt;!-- ... --&gt; ]]></script>
 </div></div><h3 id="SEDA-UseofRequestReply">Use of Request Reply</h3><p>The <a shape="rect" href="seda.html">SEDA</a> component supports using <a shape="rect" href="request-reply.html">Request Reply</a>, where the caller will wait for the <a shape="rect" href="async.html">Async</a> route to complete. For instance:</p><div class="code panel pdl" style="border-width: 1px;"><div class="codeContent panelContent pdl">
-<script class="brush: java; gutter: false; theme: Default" type="syntaxhighlighter"><![CDATA[from(&quot;mina:tcp://0.0.0.0:9876?textline=true&amp;sync=true&quot;).to(&quot;seda:input&quot;);
+<script class="brush: java; gutter: false; theme: Default" type="syntaxhighlighter"><![CDATA[from(&quot;mina:tcp://0.0.0.0:9876?textline=true&amp;sync=true&quot;)
+  .to(&quot;seda:input&quot;);
 
-from(&quot;seda:input&quot;).to(&quot;bean:processInput&quot;).to(&quot;bean:createResponse&quot;);
-]]></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 <code>seda:input</code> queue. 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 <code>seda:input</code> queue is complete, it copies the response to the original message response.</p><div class="confluence-information-macro confluence-information-macro-note"><p class="title">until 2.2: Works only with 2 endpoints</p><span class="aui-icon aui-icon-small aui-iconfont-warning confluence-information-macro-icon"></span><div class="confluence-information-macro-body"><p>Using <a shape="rect" href="request-reply.html">Request Reply</a> over <a shape="rect" href="seda.html">SEDA</a> or <a shape="rect" href="vm.html">VM</a> only works with 2 endpoints. You <strong>cannot</strong> chain endpoints by sending to A -&gt; B -&gt; C etc. Only between A -&gt; B. The reason is the implement
 ation logic is fairly simple. To support 3+ endpoints makes the logic much more complex to handle ordering and notification between the waiting threads properly.</p><p>This has been improved in <strong>Camel 2.3</strong> onwards, which allows you to chain as many endpoints as you like.</p></div></div><h3 id="SEDA-Concurrentconsumers">Concurrent consumers</h3><p>By default, the SEDA 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="brush: java; gutter: false; theme: Default" type="syntaxhighlighter"><![CDATA[from(&quot;seda:stageName?concurrentConsumers=5&quot;).process(...)
-]]></script>
-</div></div><p>As for the difference between the two, note a <em>thread pool</em> can increase/shrink dynamically at runtime depending on load, whereas the number of concurrent consumers is always fixed.</p><h3 id="SEDA-Threadpools">Thread pools</h3><p>Be aware that adding a thread pool to a SEDA endpoint by doing something like:</p><div class="code panel pdl" style="border-width: 1px;"><div class="codeContent panelContent pdl">
-<script class="brush: java; gutter: false; theme: Default" type="syntaxhighlighter"><![CDATA[from(&quot;seda:stageName&quot;).thread(5).process(...)
-]]></script>
-</div></div><p>Can wind up with two <code>BlockQueues</code>: one from the SEDA endpoint, and one from the workqueue of the thread pool, which may not be what you want. Instead, you might wish to configure a <a shape="rect" href="direct.html">Direct</a> endpoint with a thread pool, which can process messages both synchronously and asynchronously. For example:</p><div class="code panel pdl" style="border-width: 1px;"><div class="codeContent panelContent pdl">
-<script class="brush: java; gutter: false; theme: Default" type="syntaxhighlighter"><![CDATA[from(&quot;direct:stageName&quot;).thread(5).process(...)
+from(&quot;seda:input&quot;)
+  .to(&quot;bean:processInput&quot;)
+  .to(&quot;bean:createResponse&quot;);
+]]></script>
+</div></div><p>In the route above, we have a TCP listener on port&#160;<strong><code>9876</code></strong> that accepts incoming requests. The request is routed to the <strong><code>seda:input</code></strong> queue. 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 <strong><code>seda:input</code></strong> queue is complete, it copies the response to the original message response.</p><div class="confluence-information-macro confluence-information-macro-note"><p class="title">until 2.2: Works only with 2 endpoints</p><span class="aui-icon aui-icon-small aui-iconfont-warning confluence-information-macro-icon"></span><div class="confluence-information-macro-body"><p>Using <a shape="rect" href="request-reply.html">Request Reply</a> over <a shape="rect" href="seda.html">SEDA</a> or <a shape="rect" href="vm.html">VM</a> only works with 2 endpoints. You <strong>cannot</strong> chain endpoints by sending to&#160;
 <strong><code>A -&gt; B -&gt; C</code></strong> etc. Only between <strong><code>A -&gt; B</code></strong>. The reason is the implementation logic is fairly simple. To support 3+ endpoints makes the logic much more complex to handle ordering and notification between the waiting threads properly.</p><p>This has been improved in <strong>Camel 2.3</strong>, which allows you to chain as many endpoints as you like.</p></div></div><h3 id="SEDA-Concurrentconsumers">Concurrent consumers</h3><p>By default, the SEDA 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="brush: java; gutter: false; theme: Default" type="syntaxhighlighter"><![CDATA[from(&quot;seda:stageName?concurrentConsumers=5&quot;)
+  .process(...)
+]]></script>
+</div></div><p>As for the difference between the two, note a <em>thread pool</em> can increase/shrink dynamically at runtime depending on load, whereas the number of concurrent consumers is always fixed.</p><h3 id="SEDA-Threadpools">Thread pools</h3><p>Be aware that adding a thread pool to a&#160;<strong>seda</strong> endpoint by doing something like:</p><div class="code panel pdl" style="border-width: 1px;"><div class="codeContent panelContent pdl">
+<script class="brush: java; gutter: false; theme: Default" type="syntaxhighlighter"><![CDATA[from(&quot;seda:stageName&quot;)
+  .thread(5)
+  .process(...)
+]]></script>
+</div></div><p>Can wind up with two <strong><code>BlockQueues</code>:</strong> one from the&#160;<strong>seda</strong> endpoint, and one from the workqueue of the thread pool, which may not be what you want. Instead, you might wish to configure a <a shape="rect" href="direct.html">Direct</a> endpoint with a thread pool, which can process messages both synchronously and asynchronously. For example:</p><div class="code panel pdl" style="border-width: 1px;"><div class="codeContent panelContent pdl">
+<script class="brush: java; gutter: false; theme: Default" type="syntaxhighlighter"><![CDATA[from(&quot;direct:stageName&quot;)
+  .thread(5)
+  .process(...)
 ]]></script>
-</div></div><p>You can also directly configure number of threads that process messages on a SEDA endpoint using the <code>concurrentConsumers</code> option.</p><h3 id="SEDA-Sample">Sample</h3><p>In the route below we use the SEDA queue 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">
+</div></div><p>You can also directly configure number of threads that process messages on a&#160;<strong>seda</strong> endpoint using the <strong><code>concurrentConsumers</code></strong> option.</p><h3 id="SEDA-Sample">Sample</h3><p>In the route below we use the SEDA queue to send the request to this asynchronous 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="brush: java; gutter: false; theme: Default" type="syntaxhighlighter"><![CDATA[
 public void configure() throws Exception {
     from(&quot;direct:start&quot;)
@@ -137,7 +149,7 @@ public void configure() throws Exception
 Object out = template.requestBody(&quot;direct:start&quot;, &quot;Hello World&quot;);
 assertEquals(&quot;OK&quot;, out);
 ]]></script>
-</div></div>The "Hello World" message will be consumed from the SEDA queue from another thread for further processing. Since this is from a unit test, it will be sent to a <code>mock</code> endpoint where we can do assertions in the unit test.<h3 id="SEDA-UsingmultipleConsumers">Using multipleConsumers</h3><p><strong>Available as of Camel 2.2</strong></p><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">
+</div></div>The&#160;<strong><code>Hello World</code></strong> message will be consumed from the&#160;<strong>seda</strong> queue from another thread for further processing. Since this is from a unit test, it will be sent to a <strong><code>mock</code></strong> endpoint where we can do assertions in the unit test.<h3 id="SEDA-UsingmultipleConsumers">Using&#160;<code>multipleConsumers</code></h3><p><strong>Available as of Camel 2.2</strong></p><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="brush: xml; gutter: false; theme: Default" type="syntaxhighlighter"><![CDATA[
 &lt;!-- define the consumers as spring beans --&gt;
 &lt;bean id=&quot;consumer1&quot; class=&quot;org.apache.camel.spring.example.FooEventConsumer&quot;/&gt;
@@ -149,7 +161,7 @@ assertEquals(&quot;OK&quot;, out);
     &lt;endpoint id=&quot;foo&quot; uri=&quot;seda:foo?multipleConsumers=true&quot;/&gt;
 &lt;/camelContext&gt;
 ]]></script>
-</div></div>Since we have specified <strong>multipleConsumers=true</strong> on the seda foo endpoint we can have those two consumers receive their own copy of the message as a kind of pub-sub style messaging.<p>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 seda queue.</p><div class="code panel pdl" style="border-width: 1px;"><div class="codeContent panelContent pdl">
+</div></div>Since we have specified <strong><code>multipleConsumers=true</code></strong> on the <strong>seda</strong>&#160;<strong><code>foo</code></strong> endpoint we can have those two consumers receive their own copy of the message as a kind of pub-sub style messaging.<p>As the beans are part of an unit test they simply send the message to a&#160;<strong><code>mock</code></strong> endpoint. Note the use of <strong><code>@Consume</code></strong> to consume from the <strong>seda</strong> queue.</p><div class="code panel pdl" style="border-width: 1px;"><div class="codeContent panelContent pdl">
 <script class="brush: java; gutter: false; theme: Default" type="syntaxhighlighter"><![CDATA[
 public class FooEventConsumer {
 
@@ -163,7 +175,7 @@ public class FooEventConsumer {
 
 }
 ]]></script>
-</div></div><h3 id="SEDA-Extractingqueueinformation.">Extracting queue information.</h3><p>If needed, information such as queue 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">
+</div></div><h3 id="SEDA-ExtractingQueueInformation.">Extracting Queue Information.</h3><p>If needed, information such as queue 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="brush: java; gutter: false; theme: Default" type="syntaxhighlighter"><![CDATA[SedaEndpoint seda = context.getEndpoint(&quot;seda:xxxx&quot;);
 int size = seda.getExchanges().size();
 ]]></script>



Mime
View raw message