Author: buildbot
Date: Tue Oct 18 17:19:28 2016
New Revision: 999619
Log:
Production update by buildbot for camel
Modified:
websites/production/camel/content/asynchronous-processing.html
websites/production/camel/content/book-component-appendix.html
websites/production/camel/content/book-cookbook.html
websites/production/camel/content/book-in-one-page.html
websites/production/camel/content/cache/main.pageCache
websites/production/camel/content/exception-clause.html
websites/production/camel/content/jetty.html
Modified: websites/production/camel/content/asynchronous-processing.html
==============================================================================
--- websites/production/camel/content/asynchronous-processing.html (original)
+++ websites/production/camel/content/asynchronous-processing.html Tue Oct 18
17:19:28 2016
@@ -84,61 +84,17 @@
<tbody>
<tr>
<td valign="top" width="100%">
-<div class="wiki-content maincontent"><h2
id="AsynchronousProcessing-AsynchronousProcessing">Asynchronous Processing</h2>
-
-<h3 id="AsynchronousProcessing-Overview">Overview</h3>
-
-<div class="confluence-information-macro
confluence-information-macro-information"><p class="title">Supported
versions</p><span class="aui-icon aui-icon-small aui-iconfont-info
confluence-information-macro-icon"></span><div
class="confluence-information-macro-body">
-<p>The information on this page applies for Camel 2.4 onwards. Before Camel
2.4 the asynchronous processing is only implemented for <a shape="rect"
href="jbi.html">JBI</a> where as in Camel 2.4 onwards we have implemented it in
many other areas. See more at <a shape="rect"
href="asynchronous-routing-engine.html">Asynchronous Routing
Engine</a>.</p></div></div>
-
-<p>Camel supports a more complex asynchronous processing model. The
asynchronous processors implement the AsyncProcessor interface which is derived
from the more synchronous Processor interface. There are advantages and
disadvantages when using asynchronous processing when compared to using the
standard synchronous processing model.</p>
-
-<p>Advantages:</p>
-<ul><li>Processing routes that are composed fully of asynchronous processors
do not use up threads waiting for processors to complete on blocking calls.
This can increase the scalability of your system by reducing the number of
threads needed to process the same workload.</li><li>Processing routes can be
broken up into <a shape="rect" href="seda.html">SEDA</a> processing stages
where different thread pools can process the different stages. This means that
your routes can be processed concurrently.</li></ul>
-
-
-<p>Disadvantages:</p>
-<ul><li>Implementing asynchronous processors is more complex than implementing
the synchronous versions.</li></ul>
-
-
-<h3 id="AsynchronousProcessing-WhentoUse">When to Use</h3>
-
-<p>We recommend that processors and components be implemented the more simple
synchronous APIs unless you identify a performance of scalability requirement
that dictates otherwise. A Processor whose process() method blocks for a long
time would be good candidates for being converted into an asynchronous
processor.</p>
-
-<h3 id="AsynchronousProcessing-InterfaceDetails">Interface Details</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[
-public interface AsyncProcessor extends Processor {
+<div class="wiki-content maincontent"><h2
id="AsynchronousProcessing-AsynchronousProcessing">Asynchronous
Processing</h2><h3 id="AsynchronousProcessing-Overview">Overview</h3><div
class="confluence-information-macro
confluence-information-macro-information"><p class="title">Supported
versions</p><span class="aui-icon aui-icon-small aui-iconfont-info
confluence-information-macro-icon"></span><div
class="confluence-information-macro-body"><p>The information on this page
applies for <strong>Camel 2.4</strong> or later.</p><p>Before <strong>Camel
2.4</strong> the asynchronous processing is only implemented for <a
shape="rect" href="jbi.html">JBI</a> where as in <strong>Camel 2.4</strong> we
have implemented it in many other areas. See more at <a shape="rect"
href="asynchronous-routing-engine.html">Asynchronous Routing
Engine</a>.</p></div></div><p>Camel supports a more complex asynchronous
processing model. The asynchronous processors implement the
<strong><code>org.apache.camel.AsyncPr
ocessor</code></strong> interface which is derived from the more synchronous
<strong><code>org.apache.camel.Processor</code></strong> interface. There are
advantages and disadvantages when using asynchronous processing when compared
to using the standard synchronous processing
model.</p><p><strong>Advantages</strong>:</p><ul><li>Processing routes that are
composed fully of asynchronous processors do not use up threads waiting for
processors to complete on blocking calls. This can increase the scalability of
your system by reducing the number of threads needed to process the same
workload.</li><li>Processing routes can be broken up into <a shape="rect"
href="seda.html">SEDA</a> processing stages where different thread pools can
process the different stages. This means that your routes can be processed
concurrently.</li></ul><p><strong>Disadvantages</strong>:</p><ul><li>Implementing
asynchronous processors is more complex than implementing the synchronous
versions.</li></ul><h3 id="As
ynchronousProcessing-WhentoUse">When to Use</h3><p>We recommend that
processors and components be implemented the more simple synchronous APIs
unless you identify a performance of scalability requirement that dictates
otherwise. A Processor whose <strong><code>process()</code></strong>
method blocks for a long time would be good candidates for being converted into
an asynchronous processor.</p><h3
id="AsynchronousProcessing-InterfaceDetails">Interface Details</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[public interface AsyncProcessor extends
Processor {
boolean process(Exchange exchange, AsyncCallback callback);
}
]]></script>
-</div></div>
-
-<p>The AsyncProcessor defines a single <code>process()</code> method which is
very similar to it's synchronous Processor.process() brethren. Here are the
differences:</p>
-<ul><li>A non-null AsyncCallback <strong>MUST</strong> be supplied which will
be notified when the exchange processing is completed.</li><li>It
<strong>MUST</strong> not throw any exceptions that occurred while processing
the exchange. Any such exceptions must be stored on the exchange's Exception
property.</li><li>It <strong>MUST</strong> know if it will complete the
processing synchronously or asynchronously. The method will return
<code>true</code> if it does complete synchronously, otherwise it returns
<code>false</code>.</li><li>When the processor has completed processing the
exchange, it must call the <code>callback.done(boolean sync)</code> method.
The sync parameter <strong>MUST</strong> match the value returned by the
<code>process()</code> method.</li></ul>
-
-
-<h3
id="AsynchronousProcessing-ImplementingProcessorsthatUsetheAsyncProcessorAPI">Implementing
Processors that Use the AsyncProcessor API</h3>
-
-<p>All processors, even synchronous processors that do not implement the
AsyncProcessor interface, can be coerced to implement the AsyncProcessor
interface. This is usually done when you are implementing a Camel component
consumer that supports asynchronous completion of the exchanges that it is
pushing through the Camel routes. Consumers are provided a Processor object
when created. All Processor object can be coerced to a AsyncProcessor using
the following API:</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[
-Processor processor = ...
+</div></div><p>The <strong><code>AsyncProcessor</code></strong> defines a
single <strong><code>process()</code></strong> method which is very similar to
it's synchronous <strong><code>Processor.process()</code></strong>
brethren.</p><p>Here are the differences:</p><ul><li>A
non-null <strong><code>AsyncCallback</code></strong> <strong>MUST</strong>
be supplied which will be notified when the exchange processing is
completed.</li><li>It <strong>MUST</strong> not throw any exceptions that
occurred while processing the exchange. Any such exceptions must be stored on
the exchange's <strong><code>Exception</code></strong>
property.</li><li>It <strong>MUST</strong> know if it will complete the
processing synchronously or asynchronously. The method will return
<strong><code>true</code></strong> if it does complete synchronously, otherwise
it returns <strong><code>false</code></strong>.</li><li>When the processor has
completed processing the exchange, it must call the <st
rong><code>callback.done(boolean sync)</code></strong> method.</li><li>The
sync parameter <strong>MUST</strong> match the value returned by the
<strong><code>process()</code></strong> method.</li></ul><h3
id="AsynchronousProcessing-ImplementingProcessorsthatUsetheAsyncProcessorAPI">Implementing
Processors that Use the AsyncProcessor API</h3><p>All processors, even
synchronous processors that do not implement
the <strong><code>AsyncProcessor</code></strong> interface, can be coerced
to implement the <strong><code>AsyncProcessor</code></strong> interface.
This is usually done when you are implementing a Camel component consumer that
supports asynchronous completion of the exchanges that it is pushing through
the Camel routes. Consumers are provided
a <strong><code>Processor</code></strong> object when created. All
Processor object can be coerced to
a <strong><code>AsyncProcessor</code></strong> using the following
API:</p><div class="code panel pdl" style="border-w
idth: 1px;"><div class="codeContent panelContent pdl">
+<script class="brush: java; gutter: false; theme: Default"
type="syntaxhighlighter"><![CDATA[Processor processor = ...
AsyncProcessor asyncProcessor = AsyncProcessorTypeConverter.convert(processor);
]]></script>
-</div></div>
-
-<p>For a route to be fully asynchronous and reap the benefits to lower Thread
usage, it must start with the consumer implementation making use of the
asynchronous processing API. If it called the synchronous process() method
instead, the consumer's thread would be forced to be blocked and in use for the
duration that it takes to process the exchange.</p>
-
-<p>It is important to take note that just because you call the asynchronous
API, it does not mean that the processing will take place asynchronously. It
only allows the possibility that it can be done without tying up the caller's
thread. If the processing happens asynchronously is dependent on the
configuration of the Camel route.</p>
-
-<p>Normally, the the process call is passed in an inline inner AsyncCallback
class instance which can reference the exchange object that was declared final.
This allows it to finish up any post processing that is needed when the
called processor is done processing the exchange. See below for an 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[
-final Exchange exchange = ...
+</div></div><p>For a route to be fully asynchronous and reap the benefits to
lower Thread usage, it must start with the consumer implementation making use
of the asynchronous processing API. If it called the
synchronous <strong><code>process()</code></strong> method instead, the
consumer's thread would be forced to be blocked and in use for the duration
that it takes to process the exchange.</p><p>It is important to take note that
just because you call the asynchronous API, it does not mean that the
processing will take place asynchronously. It only allows the possibility that
it can be done without tying up the caller's thread. If the processing happens
asynchronously is dependent on the configuration of the Camel
route.</p><p>Normally, the the process call is passed in an inline
inner <strong><code>AsyncCallback</code></strong> class instance which can
reference the exchange object that was declared final. This allows it to finish
up any post processing that is needed wh
en the called processor is done processing the
exchange.</p><p>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[final Exchange exchange = ...
AsyncProcessor asyncProcessor = ...
asyncProcessor.process(exchange, new AsyncCallback() {
public void done(boolean sync) {
@@ -152,53 +108,18 @@ asyncProcessor.process(exchange, new Asy
}
});
]]></script>
-</div></div>
-
-
-<h3
id="AsynchronousProcessing-AsynchronousRouteSequenceScenarios">Asynchronous
Route Sequence Scenarios</h3>
-
-<p>Now that we have understood the interface contract of the AsyncProcessor,
and have seen how to make use of it when calling processors, lets looks a what
the thread model/sequence scenarios will look like for some sample routes.</p>
-
-<p>The Jetty component's consumers support async processing by using
continuations. Suffice to say it can take a http request and pass it to a
camel route for async processing. If the processing is indeed async, it uses
Jetty continuation so that the http request is 'parked' and the thread is
released. Once the camel route finishes processing the request, the jetty
component uses the AsyncCallback to tell Jetty to 'un-park' the request. Jetty
un-parks the request, the http response returned using the result of the
exchange processing.</p>
-
-<p>Notice that the jetty continuations feature is only used "If the processing
is indeed async". This is why AsyncProcessor.process() implementations MUST
accurately report if request is completed synchronously or not. </p>
-
-<p>The jhc component's producer allows you to make HTTP requests and implement
the AsyncProcessor interface. A route that uses both the jetty asynchronous
consumer and the jhc asynchronous producer will be a fully asynchronous route
and has some nice attributes that can be seen if we take a look at a sequence
diagram of the processing route. For the route:</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("jetty:http://localhost:8080/service").to("jhc:http://localhost/service-impl");
+</div></div><h3
id="AsynchronousProcessing-AsynchronousRouteSequenceScenarios">Asynchronous
Route Sequence Scenarios</h3><p>Now that we have understood the interface
contract of the <strong><code>AsyncProcessor</code></strong>, and have seen how
to make use of it when calling processors, let's looks a what the thread
model/sequence scenarios will look like for some sample routes.</p><p>The Jetty
component's consumers support asynchronous processing through the use of
continuations. Suffice to say it can take a HTTP request and pass it to a Camel
route for asynchronous processing. If the processing is indeed asynchronous, it
uses a Jetty continuation so that the HTTP request is 'parked' and the thread
is released. Once the Camel route finishes processing the request, the Jetty
component uses the <strong><code>AsyncCallback</code></strong> to tell
Jetty to 'un-park' the request. Jetty un-parks the request, the HTTP response
returned using the result of the exchange processing.</p
><p>Notice that the jetty continuations feature is only used "If the
>processing is indeed async". This is
>why <strong><code>AsyncProcessor.process()</code></strong>
>implementations <em>must</em> accurately report if request is completed
>synchronously or not.</p><p>The <strong><code>jhc</code></strong>
>component's producer allows you to make HTTP requests and implement
>the <strong><code>AsyncProcessor</code></strong> interface. A route that
>uses both the jetty asynchronous consumer and
>the <strong><code>jhc</code></strong> asynchronous producer will be a
>fully asynchronous route and has some nice attributes that can be seen if we
>take a look at a sequence diagram of the processing route.</p><p>For the
>route:</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("jetty:http://localhost:8080/service")
+ .to("jhc:http://localhost/service-impl");
]]></script>
-</div></div>
-
-<p>The sequence diagram would look something like this:</p>
-
-<p><span class="confluence-embedded-file-wrapper"><img
class="confluence-embedded-image"
src="asynchronous-processing.data/simple-async-route.png"
data-image-src="/confluence/download/attachments/68592/simple-async-route.png?version=1&modificationDate=1192103278000&api=v2"
data-unresolved-comment-count="0" data-linked-resource-id="59670856"
data-linked-resource-version="1" data-linked-resource-type="attachment"
data-linked-resource-default-alias="simple-async-route.png"
data-base-url="https://cwiki.apache.org/confluence";
data-linked-resource-content-type="image/png"
data-linked-resource-container-id="68592"
data-linked-resource-container-version="14"></span></p>
-
-<p>The diagram simplifies things by making it looks like processors implement
the AsyncCallback interface when in reality the AsyncCallback interfaces are
inline inner classes, but it illustrates the processing flow and shows how 2
separate threads are used to complete the processing of the original http
request. The first thread is synchronous up until processing hits the jhc
producer which issues the http request. It then reports that the exchange
processing will complete async since it will use a NIO to complete getting the
response back. Once the jhc component has received a full response it uses
<code>AsyncCallback.done()</code> method to notify the caller. These callback
notifications continue up until it reaches the original jetty consumer which
then un-parks the http request and completes it by providing the response.</p>
-
-<h3
id="AsynchronousProcessing-MixingSynchronousandAsynchronousProcessors">Mixing
Synchronous and Asynchronous Processors</h3>
-
-<p>It is totally possible and reasonable to mix the use of synchronous and
asynchronous processors/components. The pipeline processor is the backbone of
a Camel processing route. It glues all the processing steps together. It is
implemented as an AsyncProcessor and supports interleaving synchronous and
asynchronous processors as the processing steps in the pipeline. </p>
-
-<p>Lets say we have 2 custom processors, MyValidator and MyTransformation,
both of which are synchronous processors. Lets say we want to load file from
the data/in directory validate them with the MyValidator() processor, Transform
them into JPA java objects using MyTransformation and then insert them into the
database using the <a shape="rect" href="jpa.html">JPA</a> component. Lets say
that the transformation process takes quite a bit of time and we want to
allocate 20 threads to do parallel transformations of the input files. The
solution is to make use of the thread processor. The thread is AsyncProcessor
that forces subsequent processing in asynchronous thread from a thread pool.</p>
-
-<p>The route might look 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("file:data/in").process(new
MyValidator()).threads(20).process(new
MyTransformation()).to("jpa:PurchaseOrder");
+</div></div><p>The sequence diagram would look something like
this:</p><p><span class="confluence-embedded-file-wrapper"><img
class="confluence-embedded-image"
src="asynchronous-processing.data/simple-async-route.png"
data-image-src="/confluence/download/attachments/68592/simple-async-route.png?version=1&modificationDate=1192103278000&api=v2"
data-unresolved-comment-count="0" data-linked-resource-id="59670856"
data-linked-resource-version="1" data-linked-resource-type="attachment"
data-linked-resource-default-alias="simple-async-route.png"
data-base-url="https://cwiki.apache.org/confluence";
data-linked-resource-content-type="image/png"
data-linked-resource-container-id="68592"
data-linked-resource-container-version="15"></span></p><p>The diagram
simplifies things by making it looks like processors implement
the <strong><code>AsyncCallback</code></strong> interface when in reality
the <strong><code>AsyncCallback</code></strong> interfaces are inline
inner classes, b
ut it illustrates the processing flow and shows how two separate threads are
used to complete the processing of the original HTTP request. The first thread
is synchronous up until processing hits
the <strong><code>jhc</code></strong> producer which issues the HTTP
request. It then reports that the exchange processing will complete
asynchronously using NIO to get the response back. Once
the <strong><code>jhc</code></strong> component has received a full
response it uses <strong><code>AsyncCallback.done()</code></strong> method to
notify the caller. These callback notifications continue up until it reaches
the original Jetty consumer which then un-parks the HTTP request and completes
it by providing the response.</p><h3
id="AsynchronousProcessing-MixingSynchronousandAsynchronousProcessors">Mixing
Synchronous and Asynchronous Processors</h3><p>It is totally possible and
reasonable to mix the use of synchronous and asynchronous
processors/components. The pipeline processo
r is the backbone of a Camel processing route. It glues all the processing
steps together. It is implemented as
an <strong><code>AsyncProcessor</code></strong> and supports interleaving
synchronous and asynchronous processors as the processing steps in the
pipeline.</p><p>Let's say we have two custom asynchronous processors,
namely: <strong><code>MyValidator</code></strong> and
<strong><code>MyTransformation</code></strong>. Let's say we want to load file
from the data/in directory validate them with
the <strong><code>MyValidator()</code></strong> processor, transform them
into JPA Java objects using <strong><code>MyTransformation</code></strong>
and then insert them into the database using the <a shape="rect"
href="jpa.html">JPA</a> component. Let's say that the transformation process
takes quite a bit of time and we want to
allocate <strong><code>20</code></strong> threads to do parallel
transformations of the input files. The solution is to make use of th
e thread processor. The thread
is <strong><code>AsyncProcessor</code></strong> that forces subsequent
processing in asynchronous thread from a thread pool.</p><p>The route might
look 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("file:data/in")
+ .process(new MyValidator())
+ .threads(20)
+ .process(new MyTransformation())
+ .to("jpa:PurchaseOrder");
]]></script>
-</div></div>
-
-<p>The sequence diagram would look something like this:</p>
-
-<p><span class="confluence-embedded-file-wrapper"><img
class="confluence-embedded-image"
src="asynchronous-processing.data/camel-mixed-processors.png"
data-image-src="/confluence/download/attachments/68592/camel-mixed-processors.png?version=1&modificationDate=1192110286000&api=v2"
data-unresolved-comment-count="0" data-linked-resource-id="59670857"
data-linked-resource-version="1" data-linked-resource-type="attachment"
data-linked-resource-default-alias="camel-mixed-processors.png"
data-base-url="https://cwiki.apache.org/confluence";
data-linked-resource-content-type="image/png"
data-linked-resource-container-id="68592"
data-linked-resource-container-version="14"></span></p>
-
-<p>You would actually have multiple threads executing the 2nd part of the
thread sequence.</p>
-
-
-<h3 id="AsynchronousProcessing-StayingsynchronousinanAsyncProcessor">Staying
synchronous in an AsyncProcessor</h3>
-
-<p>Generally speaking you get better throughput processing when you process
things synchronously. This is due to the fact that starting up an asynchronous
thread and doing a context switch to it adds a little bit of of overhead. So
it is generally encouraged that AsyncProcessors do as much work as they can
synchronously. When they get to a step that would block for a long time, at
that point they should return from the process call and let the caller know
that it will be completing the call asynchronously.</p></div>
+</div></div><p>The sequence diagram would look something like
this:</p><p><span class="confluence-embedded-file-wrapper"><img
class="confluence-embedded-image"
src="asynchronous-processing.data/camel-mixed-processors.png"
data-image-src="/confluence/download/attachments/68592/camel-mixed-processors.png?version=1&modificationDate=1192110286000&api=v2"
data-unresolved-comment-count="0" data-linked-resource-id="59670857"
data-linked-resource-version="1" data-linked-resource-type="attachment"
data-linked-resource-default-alias="camel-mixed-processors.png"
data-base-url="https://cwiki.apache.org/confluence";
data-linked-resource-content-type="image/png"
data-linked-resource-container-id="68592"
data-linked-resource-container-version="15"></span></p><p>You would actually
have multiple threads executing the second part of the thread sequence.</p><h3
id="AsynchronousProcessing-StayingSynchronousinanAsyncProcessor">Staying
Synchronous in an <code>AsyncProcessor</code></h3><p>Gene
rally speaking you get better throughput processing when you process things
synchronously. This is due to the fact that starting up an asynchronous thread
and doing a context switch to it adds a little bit of of overhead. So it is
generally encouraged that <strong><code>AsyncProcessor</code></strong>'s do as
much work as they can synchronously. When they get to a step that would block
for a long time, at that point they should return from the process call and let
the caller know that it will be completing the call asynchronously.</p></div>
</td>
<td valign="top">
<div class="navigation">
Modified: websites/production/camel/content/book-component-appendix.html
==============================================================================
--- websites/production/camel/content/book-component-appendix.html (original)
+++ websites/production/camel/content/book-component-appendix.html Tue Oct 18
17:19:28 2016
@@ -621,8 +621,8 @@ cometds://localhost:8443/service/mychann
<div class="confluence-information-macro-body">
<p>When using CXF in streaming modes (see DataFormat option), then also read
about <a shape="rect" href="stream-caching.html">Stream caching</a>.</p>
</div>
-</div><p>The <strong>cxf:</strong> component provides integration with <a
shape="rect" href="http://cxf.apache.org";>Apache CXF</a> for connecting to
JAX-WS services hosted in CXF.</p><p><style type="text/css">/**/
div.rbtoc1476807479027 {padding: 0px;} div.rbtoc1476807479027 ul {list-style:
disc;margin-left: 0px;} div.rbtoc1476807479027 li {margin-left:
0px;padding-left: 0px;} /**/</style>
- </p><div class="toc-macro rbtoc1476807479027">
+</div><p>The <strong>cxf:</strong> component provides integration with <a
shape="rect" href="http://cxf.apache.org";>Apache CXF</a> for connecting to
JAX-WS services hosted in CXF.</p><p><style type="text/css">/**/
div.rbtoc1476811063800 {padding: 0px;} div.rbtoc1476811063800 ul {list-style:
disc;margin-left: 0px;} div.rbtoc1476811063800 li {margin-left:
0px;padding-left: 0px;} /**/</style>
+ </p><div class="toc-macro rbtoc1476811063800">
<ul class="toc-indentation"><li><a shape="rect"
href="#BookComponentAppendix-CXFComponent">CXF Component</a>
<ul class="toc-indentation"><li><a shape="rect"
href="#BookComponentAppendix-URIformat">URI format</a></li><li><a shape="rect"
href="#BookComponentAppendix-Options">Options</a>
<ul class="toc-indentation"><li><a shape="rect"
href="#BookComponentAppendix-Thedescriptionsofthedataformats">The descriptions
of the dataformats</a>
@@ -2940,7 +2940,7 @@ cometds://localhost:8443/service/mychann
</div><p>Jetty also needs to know where to load your keystore from and what
passwords to use in order to load the correct SSL certificate. Set the
following JVM System Properties:</p><p><strong>Before Camel
2.3</strong>:</p><div class="table-wrap">
<table class="confluenceTable"><tbody><tr><th colspan="1" rowspan="1"
class="confluenceTh">Property</th><th colspan="1" rowspan="1"
class="confluenceTh">Description</th></tr><tr><td colspan="1" rowspan="1"
class="confluenceTd"><code>jetty.ssl.keystore</code></td><td colspan="1"
rowspan="1" class="confluenceTd">Specifies the location of the
Java <strong><code>keystore</code></strong> file, which contains the Jetty
server's own <strong><code>X.509</code></strong> certificate in a <em>key
entry</em>. A key entry stores the <strong><code>X.509</code></strong>
certificate (effectively, the <em>public key</em>) and also its associated
private key.</td></tr><tr><td colspan="1" rowspan="1"
class="confluenceTd"><code>jetty.ssl.password</code></td><td colspan="1"
rowspan="1" class="confluenceTd">The store password, which is required to
access the <strong><code>keystore</code></strong> file (this is the same
password that is supplied to the <strong><code>keystore</code></s
trong> command's <strong><code>-storepass</code></strong>
option).</td></tr><tr><td colspan="1" rowspan="1"
class="confluenceTd"><code>jetty.ssl.keypassword</code></td><td colspan="1"
rowspan="1" class="confluenceTd">The key password, which is used to access the
certificate's key entry in the <strong><code>keystore</code></strong>
(this is the same password that is supplied to the
<strong><code>keystore</code></strong> command's
<strong><code>-keypass</code></strong> option).</td></tr></tbody></table>
</div><p> </p><p><strong>From Camel 2.3</strong>:</p><div
class="table-wrap">
- <table class="confluenceTable"><tbody><tr><th colspan="1" rowspan="1"
class="confluenceTh"> </th><th colspan="1" rowspan="1"
class="confluenceTh"> </th></tr><tr><td colspan="1" rowspan="1"
class="confluenceTd"><code>org.eclipse.jetty.ssl.keystore</code></td><td
colspan="1" rowspan="1" class="confluenceTd">Specifies the location of the
Java <strong><code>keystore</code></strong> file, which contains the Jetty
server's own <strong><code>X.509</code></strong> certificate in a <em>key
entry</em>. A key entry stores the <strong><code>X.509</code></strong>
certificate (effectively, the <em>public key</em>) and also its associated
private key.</td></tr><tr><td colspan="1" rowspan="1"
class="confluenceTd"><code>org.eclipse.jetty.ssl.password</code></td><td
colspan="1" rowspan="1" class="confluenceTd">The store password, which is
required to access the <strong><code>keystore</code></strong> file (this
is the same password that is supplied to the <strong><c
ode>keystore</code></strong>
command's <strong><code>keystore</code></strong> option).</td></tr><tr><td
colspan="1" rowspan="1"
class="confluenceTd"><code>org.eclipse.jetty.ssl.keypassword</code></td><td
colspan="1" rowspan="1" class="confluenceTd">The key password, which is used to
access the certificate's key entry in
the <strong><code>keystore</code></strong> (this is the same password that
is supplied to the <strong><code>keystore</code></strong>
command's <strong><code>keystore</code></strong>
option).</td></tr></tbody></table>
+ <table class="confluenceTable"><tbody><tr><th colspan="1" rowspan="1"
class="confluenceTh">Property</th><th colspan="1" rowspan="1"
class="confluenceTh">Description</th></tr><tr><td colspan="1" rowspan="1"
class="confluenceTd"><code>org.eclipse.jetty.ssl.keystore</code></td><td
colspan="1" rowspan="1" class="confluenceTd">Specifies the location of the
Java <strong><code>keystore</code></strong> file, which contains the Jetty
server's own <strong><code>X.509</code></strong> certificate in a <em>key
entry</em>. A key entry stores the <strong><code>X.509</code></strong>
certificate (effectively, the <em>public key</em>) and also its associated
private key.</td></tr><tr><td colspan="1" rowspan="1"
class="confluenceTd"><code>org.eclipse.jetty.ssl.password</code></td><td
colspan="1" rowspan="1" class="confluenceTd">The store password, which is
required to access the <strong><code>keystore</code></strong> file (this
is the same password that is supplied to the <st
rong><code>keystore</code></strong>
command's <strong><code>keystore</code></strong> option).</td></tr><tr><td
colspan="1" rowspan="1"
class="confluenceTd"><code>org.eclipse.jetty.ssl.keypassword</code></td><td
colspan="1" rowspan="1" class="confluenceTd">The key password, which is used to
access the certificate's key entry in
the <strong><code>keystore</code></strong> (this is the same password that
is supplied to the <strong><code>keystore</code></strong>
command's <strong><code>keystore</code></strong>
option).</td></tr></tbody></table>
</div><p>For details of how to configure SSL on a Jetty endpoint, read the
following <a shape="rect" class="external-link"
href="http://www.eclipse.org/jetty/documentation/current/configuring-ssl.html";
rel="nofollow">Jetty documentation</a>.</p><p>Some SSL properties aren't
exposed directly by Camel, however Camel does expose the underlying
<strong><code>SslSocketConnector</code></strong>, which will allow you to set
properties like <strong><code>needClientAuth</code></strong> for mutual
authentication requiring a client certificate
or <strong><code>wantClientAuth</code></strong> for mutual authentication
where a client doesn't need a certificate but can have one.</p><p>There's a
slight difference between the various Camel versions:</p><p><strong>Up to Camel
2.2</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">&lt;bean id=&quot;jetty&quot;
class=&quot;org.apache.camel.component.jetty.JettyHttpComponent&quot;&gt;
&lt;property name=&quot;sslSocketConnectors&quot;&gt;
&lt;map&gt; &lt;entry key=&quot;8043&quot;&gt;
&lt;bean
class=&quot;org.mortbay.jetty.security.SslSocketConnector&quot;&gt;
&lt;property
name=&quot;password&quot;value=&quot;...&quot;/&gt;
&lt;property
name=&quot;keyPassword&quot;value=&quot;...&quot;/&gt;
&lt;property
name=&quot;keystore&quot;value=&quot;...&quot;/&gt;
&lt;property
name=&quot;needClientAuth&quot;value=&quot;...&quot;/&gt;
&lt;property
name=&quot;truststore&quot;value=&quot;...&quot;/&gt;
&lt;/bean&gt; &lt;/entry&gt; &lt;/map&gt;
&lt;/property&gt; &a
mp;lt;/bean&gt; </script>
Modified: websites/production/camel/content/book-cookbook.html
==============================================================================
--- websites/production/camel/content/book-cookbook.html (original)
+++ websites/production/camel/content/book-cookbook.html Tue Oct 18 17:19:28
2016
@@ -2201,61 +2201,17 @@ public class MyModule extends CamelModul
<script class="brush: java; gutter: false; theme: Default"
type="syntaxhighlighter"><![CDATA[from("activemq:a").setHeader(JmsConstants.JMS_X_GROUP_ID,
xpath("/invoice/productCode")).to("activemq:b");
]]></script>
</div></div><p>You can of course use the <a shape="rect"
href="xml-configuration.html">Xml Configuration</a> if you prefer</p>
-<h2 id="Bookcookbook-AsynchronousProcessing">Asynchronous Processing</h2>
-
-<h3 id="Bookcookbook-Overview">Overview</h3>
-
-<div class="confluence-information-macro
confluence-information-macro-information"><p class="title">Supported
versions</p><span class="aui-icon aui-icon-small aui-iconfont-info
confluence-information-macro-icon"></span><div
class="confluence-information-macro-body">
-<p>The information on this page applies for Camel 2.4 onwards. Before Camel
2.4 the asynchronous processing is only implemented for <a shape="rect"
href="jbi.html">JBI</a> where as in Camel 2.4 onwards we have implemented it in
many other areas. See more at <a shape="rect"
href="asynchronous-routing-engine.html">Asynchronous Routing
Engine</a>.</p></div></div>
-
-<p>Camel supports a more complex asynchronous processing model. The
asynchronous processors implement the AsyncProcessor interface which is derived
from the more synchronous Processor interface. There are advantages and
disadvantages when using asynchronous processing when compared to using the
standard synchronous processing model.</p>
-
-<p>Advantages:</p>
-<ul><li>Processing routes that are composed fully of asynchronous processors
do not use up threads waiting for processors to complete on blocking calls.
This can increase the scalability of your system by reducing the number of
threads needed to process the same workload.</li><li>Processing routes can be
broken up into <a shape="rect" href="seda.html">SEDA</a> processing stages
where different thread pools can process the different stages. This means that
your routes can be processed concurrently.</li></ul>
-
-
-<p>Disadvantages:</p>
-<ul><li>Implementing asynchronous processors is more complex than implementing
the synchronous versions.</li></ul>
-
-
-<h3 id="Bookcookbook-WhentoUse">When to Use</h3>
-
-<p>We recommend that processors and components be implemented the more simple
synchronous APIs unless you identify a performance of scalability requirement
that dictates otherwise. A Processor whose process() method blocks for a long
time would be good candidates for being converted into an asynchronous
processor.</p>
-
-<h3 id="Bookcookbook-InterfaceDetails">Interface Details</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[
-public interface AsyncProcessor extends Processor {
+<h2 id="Bookcookbook-AsynchronousProcessing">Asynchronous Processing</h2><h3
id="Bookcookbook-Overview">Overview</h3><div
class="confluence-information-macro
confluence-information-macro-information"><p class="title">Supported
versions</p><span class="aui-icon aui-icon-small aui-iconfont-info
confluence-information-macro-icon"></span><div
class="confluence-information-macro-body"><p>The information on this page
applies for <strong>Camel 2.4</strong> or later.</p><p>Before <strong>Camel
2.4</strong> the asynchronous processing is only implemented for <a
shape="rect" href="jbi.html">JBI</a> where as in <strong>Camel 2.4</strong> we
have implemented it in many other areas. See more at <a shape="rect"
href="asynchronous-routing-engine.html">Asynchronous Routing
Engine</a>.</p></div></div><p>Camel supports a more complex asynchronous
processing model. The asynchronous processors implement the
<strong><code>org.apache.camel.AsyncProcessor</code></strong> interface which
is derived from th
e more synchronous <strong><code>org.apache.camel.Processor</code></strong>
interface. There are advantages and disadvantages when using asynchronous
processing when compared to using the standard synchronous processing
model.</p><p><strong>Advantages</strong>:</p><ul><li>Processing routes that are
composed fully of asynchronous processors do not use up threads waiting for
processors to complete on blocking calls. This can increase the scalability of
your system by reducing the number of threads needed to process the same
workload.</li><li>Processing routes can be broken up into <a shape="rect"
href="seda.html">SEDA</a> processing stages where different thread pools can
process the different stages. This means that your routes can be processed
concurrently.</li></ul><p><strong>Disadvantages</strong>:</p><ul><li>Implementing
asynchronous processors is more complex than implementing the synchronous
versions.</li></ul><h3 id="Bookcookbook-WhentoUse">When to Use</h3><p>We
recommend that
processors and components be implemented the more simple synchronous APIs
unless you identify a performance of scalability requirement that dictates
otherwise. A Processor whose <strong><code>process()</code></strong>
method blocks for a long time would be good candidates for being converted into
an asynchronous processor.</p><h3 id="Bookcookbook-InterfaceDetails">Interface
Details</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[public interface AsyncProcessor extends
Processor {
boolean process(Exchange exchange, AsyncCallback callback);
}
]]></script>
-</div></div>
-
-<p>The AsyncProcessor defines a single <code>process()</code> method which is
very similar to it's synchronous Processor.process() brethren. Here are the
differences:</p>
-<ul><li>A non-null AsyncCallback <strong>MUST</strong> be supplied which will
be notified when the exchange processing is completed.</li><li>It
<strong>MUST</strong> not throw any exceptions that occurred while processing
the exchange. Any such exceptions must be stored on the exchange's Exception
property.</li><li>It <strong>MUST</strong> know if it will complete the
processing synchronously or asynchronously. The method will return
<code>true</code> if it does complete synchronously, otherwise it returns
<code>false</code>.</li><li>When the processor has completed processing the
exchange, it must call the <code>callback.done(boolean sync)</code> method.
The sync parameter <strong>MUST</strong> match the value returned by the
<code>process()</code> method.</li></ul>
-
-
-<h3
id="Bookcookbook-ImplementingProcessorsthatUsetheAsyncProcessorAPI">Implementing
Processors that Use the AsyncProcessor API</h3>
-
-<p>All processors, even synchronous processors that do not implement the
AsyncProcessor interface, can be coerced to implement the AsyncProcessor
interface. This is usually done when you are implementing a Camel component
consumer that supports asynchronous completion of the exchanges that it is
pushing through the Camel routes. Consumers are provided a Processor object
when created. All Processor object can be coerced to a AsyncProcessor using
the following API:</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[
-Processor processor = ...
+</div></div><p>The <strong><code>AsyncProcessor</code></strong> defines a
single <strong><code>process()</code></strong> method which is very similar to
it's synchronous <strong><code>Processor.process()</code></strong>
brethren.</p><p>Here are the differences:</p><ul><li>A
non-null <strong><code>AsyncCallback</code></strong> <strong>MUST</strong>
be supplied which will be notified when the exchange processing is
completed.</li><li>It <strong>MUST</strong> not throw any exceptions that
occurred while processing the exchange. Any such exceptions must be stored on
the exchange's <strong><code>Exception</code></strong>
property.</li><li>It <strong>MUST</strong> know if it will complete the
processing synchronously or asynchronously. The method will return
<strong><code>true</code></strong> if it does complete synchronously, otherwise
it returns <strong><code>false</code></strong>.</li><li>When the processor has
completed processing the exchange, it must call the <st
rong><code>callback.done(boolean sync)</code></strong> method.</li><li>The
sync parameter <strong>MUST</strong> match the value returned by the
<strong><code>process()</code></strong> method.</li></ul><h3
id="Bookcookbook-ImplementingProcessorsthatUsetheAsyncProcessorAPI">Implementing
Processors that Use the AsyncProcessor API</h3><p>All processors, even
synchronous processors that do not implement
the <strong><code>AsyncProcessor</code></strong> interface, can be coerced
to implement the <strong><code>AsyncProcessor</code></strong> interface.
This is usually done when you are implementing a Camel component consumer that
supports asynchronous completion of the exchanges that it is pushing through
the Camel routes. Consumers are provided
a <strong><code>Processor</code></strong> object when created. All
Processor object can be coerced to
a <strong><code>AsyncProcessor</code></strong> using the following
API:</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[Processor processor = ...
AsyncProcessor asyncProcessor = AsyncProcessorTypeConverter.convert(processor);
]]></script>
-</div></div>
-
-<p>For a route to be fully asynchronous and reap the benefits to lower Thread
usage, it must start with the consumer implementation making use of the
asynchronous processing API. If it called the synchronous process() method
instead, the consumer's thread would be forced to be blocked and in use for the
duration that it takes to process the exchange.</p>
-
-<p>It is important to take note that just because you call the asynchronous
API, it does not mean that the processing will take place asynchronously. It
only allows the possibility that it can be done without tying up the caller's
thread. If the processing happens asynchronously is dependent on the
configuration of the Camel route.</p>
-
-<p>Normally, the the process call is passed in an inline inner AsyncCallback
class instance which can reference the exchange object that was declared final.
This allows it to finish up any post processing that is needed when the
called processor is done processing the exchange. See below for an 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[
-final Exchange exchange = ...
+</div></div><p>For a route to be fully asynchronous and reap the benefits to
lower Thread usage, it must start with the consumer implementation making use
of the asynchronous processing API. If it called the
synchronous <strong><code>process()</code></strong> method instead, the
consumer's thread would be forced to be blocked and in use for the duration
that it takes to process the exchange.</p><p>It is important to take note that
just because you call the asynchronous API, it does not mean that the
processing will take place asynchronously. It only allows the possibility that
it can be done without tying up the caller's thread. If the processing happens
asynchronously is dependent on the configuration of the Camel
route.</p><p>Normally, the the process call is passed in an inline
inner <strong><code>AsyncCallback</code></strong> class instance which can
reference the exchange object that was declared final. This allows it to finish
up any post processing that is needed wh
en the called processor is done processing the
exchange.</p><p>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[final Exchange exchange = ...
AsyncProcessor asyncProcessor = ...
asyncProcessor.process(exchange, new AsyncCallback() {
public void done(boolean sync) {
@@ -2269,53 +2225,18 @@ asyncProcessor.process(exchange, new Asy
}
});
]]></script>
-</div></div>
-
-
-<h3 id="Bookcookbook-AsynchronousRouteSequenceScenarios">Asynchronous Route
Sequence Scenarios</h3>
-
-<p>Now that we have understood the interface contract of the AsyncProcessor,
and have seen how to make use of it when calling processors, lets looks a what
the thread model/sequence scenarios will look like for some sample routes.</p>
-
-<p>The Jetty component's consumers support async processing by using
continuations. Suffice to say it can take a http request and pass it to a
camel route for async processing. If the processing is indeed async, it uses
Jetty continuation so that the http request is 'parked' and the thread is
released. Once the camel route finishes processing the request, the jetty
component uses the AsyncCallback to tell Jetty to 'un-park' the request. Jetty
un-parks the request, the http response returned using the result of the
exchange processing.</p>
-
-<p>Notice that the jetty continuations feature is only used "If the processing
is indeed async". This is why AsyncProcessor.process() implementations MUST
accurately report if request is completed synchronously or not. </p>
-
-<p>The jhc component's producer allows you to make HTTP requests and implement
the AsyncProcessor interface. A route that uses both the jetty asynchronous
consumer and the jhc asynchronous producer will be a fully asynchronous route
and has some nice attributes that can be seen if we take a look at a sequence
diagram of the processing route. For the route:</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("jetty:http://localhost:8080/service").to("jhc:http://localhost/service-impl");
-]]></script>
-</div></div>
-
-<p>The sequence diagram would look something like this:</p>
-
-<p><span class="confluence-embedded-file-wrapper"><img
class="confluence-embedded-image"
src="book-cookbook.data/simple-async-route.png"
data-image-src="/confluence/download/attachments/68592/simple-async-route.png?version=1&modificationDate=1192103278000&api=v2"
data-unresolved-comment-count="0" data-linked-resource-id="59670856"
data-linked-resource-version="1" data-linked-resource-type="attachment"
data-linked-resource-default-alias="simple-async-route.png"
data-base-url="https://cwiki.apache.org/confluence";
data-linked-resource-content-type="image/png"
data-linked-resource-container-id="68592"
data-linked-resource-container-version="14"></span></p>
-
-<p>The diagram simplifies things by making it looks like processors implement
the AsyncCallback interface when in reality the AsyncCallback interfaces are
inline inner classes, but it illustrates the processing flow and shows how 2
separate threads are used to complete the processing of the original http
request. The first thread is synchronous up until processing hits the jhc
producer which issues the http request. It then reports that the exchange
processing will complete async since it will use a NIO to complete getting the
response back. Once the jhc component has received a full response it uses
<code>AsyncCallback.done()</code> method to notify the caller. These callback
notifications continue up until it reaches the original jetty consumer which
then un-parks the http request and completes it by providing the response.</p>
-
-<h3 id="Bookcookbook-MixingSynchronousandAsynchronousProcessors">Mixing
Synchronous and Asynchronous Processors</h3>
-
-<p>It is totally possible and reasonable to mix the use of synchronous and
asynchronous processors/components. The pipeline processor is the backbone of
a Camel processing route. It glues all the processing steps together. It is
implemented as an AsyncProcessor and supports interleaving synchronous and
asynchronous processors as the processing steps in the pipeline. </p>
-
-<p>Lets say we have 2 custom processors, MyValidator and MyTransformation,
both of which are synchronous processors. Lets say we want to load file from
the data/in directory validate them with the MyValidator() processor, Transform
them into JPA java objects using MyTransformation and then insert them into the
database using the <a shape="rect" href="jpa.html">JPA</a> component. Lets say
that the transformation process takes quite a bit of time and we want to
allocate 20 threads to do parallel transformations of the input files. The
solution is to make use of the thread processor. The thread is AsyncProcessor
that forces subsequent processing in asynchronous thread from a thread pool.</p>
-
-<p>The route might look 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("file:data/in").process(new
MyValidator()).threads(20).process(new
MyTransformation()).to("jpa:PurchaseOrder");
+</div></div><h3
id="Bookcookbook-AsynchronousRouteSequenceScenarios">Asynchronous Route
Sequence Scenarios</h3><p>Now that we have understood the interface contract of
the <strong><code>AsyncProcessor</code></strong>, and have seen how to make use
of it when calling processors, let's looks a what the thread model/sequence
scenarios will look like for some sample routes.</p><p>The Jetty component's
consumers support asynchronous processing through the use of continuations.
Suffice to say it can take a HTTP request and pass it to a Camel route for
asynchronous processing. If the processing is indeed asynchronous, it uses a
Jetty continuation so that the HTTP request is 'parked' and the thread is
released. Once the Camel route finishes processing the request, the Jetty
component uses the <strong><code>AsyncCallback</code></strong> to tell
Jetty to 'un-park' the request. Jetty un-parks the request, the HTTP response
returned using the result of the exchange processing.</p><p>Notice
that the jetty continuations feature is only used "If the processing is
indeed async". This is
why <strong><code>AsyncProcessor.process()</code></strong> implementations
<em>must</em> accurately report if request is completed synchronously or
not.</p><p>The <strong><code>jhc</code></strong> component's producer
allows you to make HTTP requests and implement
the <strong><code>AsyncProcessor</code></strong> interface. A route that
uses both the jetty asynchronous consumer and
the <strong><code>jhc</code></strong> asynchronous producer will be a
fully asynchronous route and has some nice attributes that can be seen if we
take a look at a sequence diagram of the processing route.</p><p>For the
route:</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("jetty:http://localhost:8080/service")
+ .to("jhc:http://localhost/service-impl");
+]]></script>
+</div></div><p>The sequence diagram would look something like
this:</p><p><span class="confluence-embedded-file-wrapper"><img
class="confluence-embedded-image"
src="book-cookbook.data/simple-async-route.png"
data-image-src="/confluence/download/attachments/68592/simple-async-route.png?version=1&modificationDate=1192103278000&api=v2"
data-unresolved-comment-count="0" data-linked-resource-id="59670856"
data-linked-resource-version="1" data-linked-resource-type="attachment"
data-linked-resource-default-alias="simple-async-route.png"
data-base-url="https://cwiki.apache.org/confluence";
data-linked-resource-content-type="image/png"
data-linked-resource-container-id="68592"
data-linked-resource-container-version="15"></span></p><p>The diagram
simplifies things by making it looks like processors implement
the <strong><code>AsyncCallback</code></strong> interface when in reality
the <strong><code>AsyncCallback</code></strong> interfaces are inline
inner classes, but it illu
strates the processing flow and shows how two separate threads are used to
complete the processing of the original HTTP request. The first thread is
synchronous up until processing hits the <strong><code>jhc</code></strong>
producer which issues the HTTP request. It then reports that the exchange
processing will complete asynchronously using NIO to get the response back.
Once the <strong><code>jhc</code></strong> component has received a full
response it uses <strong><code>AsyncCallback.done()</code></strong> method to
notify the caller. These callback notifications continue up until it reaches
the original Jetty consumer which then un-parks the HTTP request and completes
it by providing the response.</p><h3
id="Bookcookbook-MixingSynchronousandAsynchronousProcessors">Mixing Synchronous
and Asynchronous Processors</h3><p>It is totally possible and reasonable to mix
the use of synchronous and asynchronous processors/components. The pipeline
processor is the backbone of
a Camel processing route. It glues all the processing steps together. It is
implemented as an <strong><code>AsyncProcessor</code></strong> and
supports interleaving synchronous and asynchronous processors as the processing
steps in the pipeline.</p><p>Let's say we have two custom asynchronous
processors, namely: <strong><code>MyValidator</code></strong> and
<strong><code>MyTransformation</code></strong>. Let's say we want to load file
from the data/in directory validate them with
the <strong><code>MyValidator()</code></strong> processor, transform them
into JPA Java objects using <strong><code>MyTransformation</code></strong>
and then insert them into the database using the <a shape="rect"
href="jpa.html">JPA</a> component. Let's say that the transformation process
takes quite a bit of time and we want to
allocate <strong><code>20</code></strong> threads to do parallel
transformations of the input files. The solution is to make use of the thread
processor.
The thread is <strong><code>AsyncProcessor</code></strong> that forces
subsequent processing in asynchronous thread from a thread pool.</p><p>The
route might look 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("file:data/in")
+ .process(new MyValidator())
+ .threads(20)
+ .process(new MyTransformation())
+ .to("jpa:PurchaseOrder");
]]></script>
-</div></div>
-
-<p>The sequence diagram would look something like this:</p>
-
-<p><span class="confluence-embedded-file-wrapper"><img
class="confluence-embedded-image"
src="book-cookbook.data/camel-mixed-processors.png"
data-image-src="/confluence/download/attachments/68592/camel-mixed-processors.png?version=1&modificationDate=1192110286000&api=v2"
data-unresolved-comment-count="0" data-linked-resource-id="59670857"
data-linked-resource-version="1" data-linked-resource-type="attachment"
data-linked-resource-default-alias="camel-mixed-processors.png"
data-base-url="https://cwiki.apache.org/confluence";
data-linked-resource-content-type="image/png"
data-linked-resource-container-id="68592"
data-linked-resource-container-version="14"></span></p>
-
-<p>You would actually have multiple threads executing the 2nd part of the
thread sequence.</p>
-
-
-<h3 id="Bookcookbook-StayingsynchronousinanAsyncProcessor">Staying synchronous
in an AsyncProcessor</h3>
-
-<p>Generally speaking you get better throughput processing when you process
things synchronously. This is due to the fact that starting up an asynchronous
thread and doing a context switch to it adds a little bit of of overhead. So
it is generally encouraged that AsyncProcessors do as much work as they can
synchronously. When they get to a step that would block for a long time, at
that point they should return from the process call and let the caller know
that it will be completing the call asynchronously.</p>
+</div></div><p>The sequence diagram would look something like
this:</p><p><span class="confluence-embedded-file-wrapper"><img
class="confluence-embedded-image"
src="book-cookbook.data/camel-mixed-processors.png"
data-image-src="/confluence/download/attachments/68592/camel-mixed-processors.png?version=1&modificationDate=1192110286000&api=v2"
data-unresolved-comment-count="0" data-linked-resource-id="59670857"
data-linked-resource-version="1" data-linked-resource-type="attachment"
data-linked-resource-default-alias="camel-mixed-processors.png"
data-base-url="https://cwiki.apache.org/confluence";
data-linked-resource-content-type="image/png"
data-linked-resource-container-id="68592"
data-linked-resource-container-version="15"></span></p><p>You would actually
have multiple threads executing the second part of the thread sequence.</p><h3
id="Bookcookbook-StayingSynchronousinanAsyncProcessor">Staying Synchronous in
an <code>AsyncProcessor</code></h3><p>Generally speaking you g
et better throughput processing when you process things synchronously. This is
due to the fact that starting up an asynchronous thread and doing a context
switch to it adds a little bit of of overhead. So it is generally encouraged
that <strong><code>AsyncProcessor</code></strong>'s do as much work as they can
synchronously. When they get to a step that would block for a long time, at
that point they should return from the process call and let the caller know
that it will be completing the call asynchronously.</p>
<h2
id="Bookcookbook-ImplementingVirtualTopicsonotherJMSproviders">Implementing
Virtual Topics on other JMS providers</h2>
<p><a shape="rect" class="external-link"
href="http://activemq.apache.org/";>ActiveMQ</a> supports <a shape="rect"
class="external-link"
href="http://activemq.apache.org/virtual-destinations.html";>Virtual Topics</a>
since durable topic subscriptions kinda suck (see <a shape="rect"
class="external-link"
href="http://activemq.apache.org/virtual-destinations.html";>this page for more
detail</a>) mostly since they don't support <a shape="rect"
href="competing-consumers.html">Competing Consumers</a>.</p>
