You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@camel.apache.org by bu...@apache.org on 2017/08/25 08:22:03 UTC
svn commit: r1017260 [3/40] - in /websites/production/camel/content: ./
cache/
Modified: websites/production/camel/content/async.html
==============================================================================
--- websites/production/camel/content/async.html (original)
+++ websites/production/camel/content/async.html Fri Aug 25 08:22:01 2017
@@ -36,17 +36,6 @@
<![endif]-->
- <link href='//camel.apache.org/styles/highlighter/styles/shCoreCamel.css' rel='stylesheet' type='text/css' />
- <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 src='//camel.apache.org/styles/highlighter/scripts/shBrushPlain.js' type='text/javascript'></script>
-
- <script type="text/javascript">
- SyntaxHighlighter.defaults['toolbar'] = false;
- SyntaxHighlighter.all();
- </script>
<title>
Apache Camel: Async
@@ -86,128 +75,18 @@
<tbody>
<tr>
<td valign="top" width="100%">
-<div class="wiki-content maincontent"><h2 id="Async-Async">Async</h2><p><strong>Available as of Camel 2.0</strong></p><p>The asynchronous API in Camel have been rewritten for Camel 2.0, and the information on this page applies for Camel 2.0 and later.</p><p>The <a shape="rect" href="async.html">Async</a> API in Camel is primarily divided in two areas:</p><ol><li>Initiating an <a shape="rect" href="async.html">Async</a> messaging from the client</li><li>Turning a route into <a shape="rect" href="async.html">Async</a> using the <strong>threads</strong> <a shape="rect" href="dsl.html">DSL</a></li></ol><p>Before we look at these two areas we start with a bit of background information and looks at the concept from at a higher level using diagrams. Then we check out the first area how a client can initiate an <a shape="rect" href="async.html">Async</a> message exchange and we also throw in the synchronous message exchange in the mix as well so we can compare and distill the difference. An
d finally we turn our attention towards the last area the new <strong>threads</strong> DSL and what it can be used for.</p><h2 id="Async-Background">Background</h2><p>The new <a shape="rect" href="async.html">Async</a> API in Camel 2.0 leverages in much greater detail the Java Concurrency API and its support for executing tasks asynchronous. Therefore the Camel <a shape="rect" href="async.html">Async</a> API should be familiar for users with knowledge of the Java Concurrency API.</p><h3 id="Async-Afewconceptstomaster">A few concepts to master</h3><p>When doing messaging there are a few aspects to keep in mind. First of all a caller can initiate a message exchange as either:</p><ul class="alternate"><li><a shape="rect" href="event-message.html">Request only</a></li><li><a shape="rect" href="request-reply.html">Request Reply</a></li></ul><p><a shape="rect" href="event-message.html">Request only</a> is when the caller sends a message but do <strong>not</strong> expect any reply. This i
s also known as fire and forget or event message. The <a shape="rect" href="request-reply.html">Request Reply</a> is when the caller sends a message and then <strong>waits for a reply</strong>. This is like the <a shape="rect" href="http.html">HTTP</a> protocol that we use every day when we surf the web. We send a request to fetch a web page and wait until the reply message comes with the web content.</p><p>In Camel a message is labeled with a Message <a shape="rect" href="exchange-pattern.html">Exchange Pattern</a> that labels whether its a request only or request reply message. Camel uses the <a shape="rect" href="jbi.html">JBI</a> term for this an uses <strong><code>InOnly</code></strong> for the request only, and <strong><code>InOut</code></strong> for the request reply.</p><p>For all message exchange they can be executed either:</p><ul class="alternate"><li>synchronous</li><li>asynchronous</li></ul><h4 id="Async-SynchronousRequestReply">Synchronous Request Reply</h4><p>A synchr
onous exchange is defined as the caller sends a message and waits until its complete before continuing.</p><p>This is illustrated in the diagram below:</p><p><span class="confluence-embedded-file-wrapper"><img class="confluence-embedded-image" src="async.data/camel_sync_request_reply.png" data-image-src="/confluence/download/attachments/117116/camel_sync_request_reply.png?version=1&modificationDate=1241917552000&api=v2" data-unresolved-comment-count="0" data-linked-resource-id="10641" data-linked-resource-version="1" data-linked-resource-type="attachment" data-linked-resource-default-alias="camel_sync_request_reply.png" data-base-url="https://cwiki.apache.org/confluence" data-linked-resource-content-type="image/png" data-linked-resource-container-id="117116" data-linked-resource-container-version="56"></span></p><ol><li>The client sends a sync <a shape="rect" href="request-reply.html">Request Reply</a> message over <a shape="rect" href="http.html">HTTP</a> to Camel. The clie
nt application will wait for the response that Camel routes and processes.</li><li>The message invokes an external <a shape="rect" href="mina.html">TCP</a> service using synchronous <a shape="rect" href="request-reply.html">Request Reply</a>. The client application still waits for the response.</li><li>The response is send back to the client.</li></ol><h4 id="Async-AsynchronousRequestReply">Asynchronous Request Reply</h4><p>On the other hand the asynchronous version is where the caller sends a message to an <a shape="rect" href="endpoint.html">Endpoint</a> and then returns immediately back to the caller. The message however is processed in another thread, the asynchronous thread. Then the caller can continue doing other work and at the same time the asynchronous thread is processing the message.</p><p>This is illustrated in the diagram below:</p><p><span class="confluence-embedded-file-wrapper"><img class="confluence-embedded-image" src="async.data/camel_async_request_reply.png" dat
a-image-src="/confluence/download/attachments/117116/camel_async_request_reply.png?version=2&modificationDate=1241928088000&api=v2" data-unresolved-comment-count="0" data-linked-resource-id="10640" data-linked-resource-version="2" data-linked-resource-type="attachment" data-linked-resource-default-alias="camel_async_request_reply.png" data-base-url="https://cwiki.apache.org/confluence" data-linked-resource-content-type="image/png" data-linked-resource-container-id="117116" data-linked-resource-container-version="56"></span></p><ol><li>The client sends an <a shape="rect" href="async.html">Async</a><a shape="rect" href="request-reply.html">Request Reply</a> message over <a shape="rect" href="http.html">HTTP</a> to Camel. The control is immediately returned to the client application, that can continue and do other work while Camel routes the message.</li><li>Camel invokes an external <a shape="rect" href="mina.html">TCP</a> service using synchronous <a shape="rect" href="reques
t-reply.html">Request Reply</a>. The client application can do other work simultaneously.</li><li>The client wants to get the reply so it uses the Future handle it got as <em>response</em> from step 1. With this handle it retrieves the reply, wait if necessary if the reply is not ready.</li></ol><p> </p><h4 id="Async-SynchronousRequestOnly">Synchronous Request Only</h4><p> </p><p>You can also do synchronous <a shape="rect" href="event-message.html">Request only</a> with Camel. The client sends a message to Camel in which a reply is not expected. However the client still waits until the message is processed completely.</p><p>This is illustrated in the diagram below:</p><p><span class="confluence-embedded-file-wrapper"><img class="confluence-embedded-image" src="async.data/camel_sync_request_only.png" data-image-src="/confluence/download/attachments/117116/camel_sync_request_only.png?version=1&modificationDate=1241923637000&api=v2" data-unresolved-comment-count="0" d
ata-linked-resource-id="10642" data-linked-resource-version="1" data-linked-resource-type="attachment" data-linked-resource-default-alias="camel_sync_request_only.png" data-base-url="https://cwiki.apache.org/confluence" data-linked-resource-content-type="image/png" data-linked-resource-container-id="117116" data-linked-resource-container-version="56"></span></p><ol><li>The client sends a <a shape="rect" href="event-message.html">Request only</a> and we can still use <a shape="rect" href="http.html">HTTP</a> despite http being <a shape="rect" href="request-reply.html">Request Reply</a> by nature.</li><li>Camel invokes an external <a shape="rect" href="mina.html">TCP</a> service using synchronous <a shape="rect" href="request-reply.html">Request Reply</a>. The client application is still waiting.</li><li>The message is processed completely and the control is returned to the client.</li></ol><p>So why do you want to use synchronous <a shape="rect" href="event-message.html">Request Only
</a>? Well if you want to know whether the message was processed successfully or not before continuing. With synchronous it allows you to wait while the message is being processed. In case the processing was successful the control is returned to the client with no notion of error. In case of failure the client can detect this as an exception is thrown. (and <strong><code>exchange.isFailed()</code></strong> returns <strong><code>true</code>).</strong></p><h3 id="Async-AsynchronousRequestOnly">Asynchronous Request Only</h3><p>As opposed to the synchronous <a shape="rect" href="event-message.html">Request Only</a> the <a shape="rect" href="async.html">Async</a> counter part will <strong>not</strong> wait for the processing of the message to complete. In this case the client can immediately continue doing other work while the message is being routed and processed in Camel.</p><p>This is illustrated in the diagram below:</p><p><span class="confluence-embedded-file-wrapper"><img class="co
nfluence-embedded-image" src="async.data/camel_async_request_only.png" data-image-src="/confluence/download/attachments/117116/camel_async_request_only.png?version=1&modificationDate=1241928107000&api=v2" data-unresolved-comment-count="0" data-linked-resource-id="10644" data-linked-resource-version="1" data-linked-resource-type="attachment" data-linked-resource-default-alias="camel_async_request_only.png" data-base-url="https://cwiki.apache.org/confluence" data-linked-resource-content-type="image/png" data-linked-resource-container-id="117116" data-linked-resource-container-version="56"></span></p><ol><li>The client sends a <a shape="rect" href="event-message.html">Request only</a> and we can still use <a shape="rect" href="http.html">HTTP</a> despite HTTP being <a shape="rect" href="request-reply.html">Request Reply</a> by nature. The control is immediately returned to the client application, that can continue and do other work while Camel routes the message.</li><li>Camel
invokes an external <a shape="rect" href="mina.html">TCP</a> service using synchronous <a shape="rect" href="request-reply.html">Request Reply</a>. The client application can do other work simultaneously.</li><li>The message completes but no result is returned to the client.<br clear="none"><br clear="none"></li></ol><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"><p><strong>Note:</strong> As Camel always returns a <strong><code>Future</code></strong> handle for <a shape="rect" href="async.html">Async</a> messaging to the client. The client can use this handler to get hold of the status of the processing whether the task is complete or an Exception occurred during processing. Note that the client is not required to do so, its perfect valid to just ignore the Future handle.</p></div></div><div class="conflue
nce-information-macro confluence-information-macro-tip"><span class="aui-icon aui-icon-small aui-iconfont-approve confluence-information-macro-icon"></span><div class="confluence-information-macro-body"><p>In case you want to know whether the <a shape="rect" href="async.html">Async</a> <a shape="rect" href="event-message.html">Request Only</a> failed, then you can use the <strong><code>Future</code></strong> handle and invoke <strong><code>get()</code></strong> and if it throws a <strong><code>ExecutionException</code></strong> then the processing failed. The caused exception is wrapped. You can invoke <strong><code>isDone()</code></strong> first to test whether the task is done or still in progress. Otherwise invoking <strong><code>get()</code></strong> will wait until the task is done.</p></div></div><p>With these diagrams in mind lets turn out attention to the <a shape="rect" href="async.html">Async</a> API and how to use it with Camel.</p><h2 id="Async-1)TheClientAPI">1) The <a
shape="rect" href="async.html">Async</a> Client API</h2><p>Camel provides the <a shape="rect" href="async.html">Async</a> Client API in the <a shape="rect" class="external-link" href="http://camel.apache.org/maven/current/camel-core/apidocs/org/apache/camel/ProducerTemplate.html">ProducerTemplate</a> where we have added about ten new methods to Camel 2.0.</p><p>We have listed the most important in the table below:</p><div class="table-wrap"><table class="confluenceTable"><tbody><tr><th colspan="1" rowspan="1" class="confluenceTh"><p>Method</p></th><th colspan="1" rowspan="1" class="confluenceTh"><p>Returns</p></th><th colspan="1" rowspan="1" class="confluenceTh"><p>Description</p></th></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><p><code>setExecutorService</code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p><code>void</code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>Is used to set the Java <strong><code>ExecutorService</code></strong>. C
amel will by default provide a <strong><code>ScheduledExecutorService</code></strong> with 5 thread in the pool.</p></td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><p><code>asyncSend</code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p><code>Future<Exchange></code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>Is used to send an async exchange to a Camel <a shape="rect" href="endpoint.html">Endpoint</a>. Camel will immediately return control to the caller thread after the task has been submitted to the executor service. This allows you to do other work while Camel processes the exchange in the other async thread.</p></td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><p><code>asyncSendBody</code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p><code>Future<Object></code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>As above but for sending body only. This is a request only messaging sty
le so no reply is expected. Uses the <strong><code>InOnly</code></strong> exchange pattern.</p></td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><p><code>asyncRequestBody</code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p><code>Future<Object></code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>As above but for sending body only. This is a <a shape="rect" href="request-reply.html">Request Reply</a> messaging style so a reply is expected. Uses the <strong><code>InOut</code></strong> exchange pattern.</p></td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><p><code>extractFutureBody</code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p><code>T</code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>Is used to get the result from the asynchronous thread using the Java Concurrency Future handle.</p></td></tr></tbody></table></div><p>The <strong><code>asyncSend</code></strong> and <strong><code>asyncReques
t</code></strong> methods return a Future handle. This handle is what the caller must use later to retrieve the asynchronous response. You can do this by using the <strong><code>extractFutureBody</code></strong> method, or just use plain Java but invoke <strong><code>get()</code></strong> on the <strong><code>Future</code></strong> handle.</p><h3 id="Async-TheClientAPIwithcallbacks">The <a shape="rect" href="async.html">Async</a> Client API with callbacks</h3><p>In addition to the Client API from above Camel provides a variation that uses <a shape="rect" href="oncompletion.html">callbacks</a> when the message <a shape="rect" href="exchange.html">Exchange</a> is done.</p><div class="table-wrap"><table class="confluenceTable"><tbody><tr><th colspan="1" rowspan="1" class="confluenceTh"><p>Method</p></th><th colspan="1" rowspan="1" class="confluenceTh"><p>Returns</p></th><th colspan="1" rowspan="1" class="confluenceTh"><p>Description</p></th></tr><tr><td colspan="1" rowspan="1" class="c
onfluenceTd"><p><code>asyncCallback</code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p><code>Future<Exchange></code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>In addition a callback is passed in as a parameter using the <strong><code>org.apache.camel.spi.Synchronization</code></strong> Callback. The callback is invoked when the message exchange is done.</p></td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><p><code>asyncCallbackSendBody</code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p><code>Future<Object></code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>As above but for sending body only. This is a request only messaging style so no reply is expected. Uses the <strong><code>InOnly</code></strong> exchange pattern.</p></td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><p><code>asyncCallbackRequestBody</code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p><code>Future
<Object></code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>As above but for sending body only. This is a <a shape="rect" href="request-reply.html">Request Reply</a> messaging style so a reply is expected. Uses the <strong><code>InOut</code></strong> exchange pattern.</p></td></tr></tbody></table></div><p>These methods also returns the <strong><code>Future</code></strong> handle in case you need them. The difference is that they invokes the callback as well when the <a shape="rect" href="exchange.html">Exchange</a> is done being routed.</p><h4 id="Async-TheFutureAPI">The Future API</h4><p>The <strong><code>java.util.concurrent.Future</code></strong> API have among others the following methods:</p><div class="table-wrap"><table class="confluenceTable"><tbody><tr><th colspan="1" rowspan="1" class="confluenceTh"><p>Method</p></th><th colspan="1" rowspan="1" class="confluenceTh"><p>Returns</p></th><th colspan="1" rowspan="1" class="confluenceTh"><p>Description
</p></th></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><p><code>isDone</code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p><code>boolean</code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>Returns a boolean whether the task is done or not. Will even return <strong><code>true</code></strong> if the tasks failed due to an exception thrown.</p></td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><p><code>get()</code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p><code>Object</code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>Gets the response of the task. In case of an exception was thrown the <strong><code>java.util.concurrent.ExecutionException</code></strong> is thrown with the caused exception.</p></td></tr></tbody></table></div><h3 id="Async-Example:AsynchronousRequestReply">Example: Asynchronous Request Reply</h3><p>Suppose we want to call a <a shape="rect" href="http.html">HTTP</a> service but it i
s usually slow and thus we do not want to block and wait for the response, as we can do other important computation. So we can initiate an <a shape="rect" href="async.html">Async</a> exchange to the <a shape="rect" href="http.html">HTTP</a> endpoint and then do other stuff while the slow <a shape="rect" href="http.html">HTTP</a> service is processing our request. And then a bit later we can use the <strong><code>Future</code></strong> handle to get the response from the <a shape="rect" href="http.html">HTTP</a> service. Yeah nice so lets do it:</p><p>First we define some routes in Camel. One for the <a shape="rect" href="http.html">HTTP</a> service where we simulate a slow server as it takes at least 1 second to reply. And then other route that we want to invoke while the <a shape="rect" href="http.html">HTTP</a> service is on route. This allows you to be able to process the two routes simultaneously:</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[
-// The mocks are here for unit test
-
-// Some other service to return a name, this is invoked synchronously
-from("direct:name").transform(constant("Claus")).to("mock:result");
-
-// Simulate a slow http service (delaying 1 sec) we want to invoke async
-fromF("jetty:http://0.0.0.0:%s/myservice", getPort())
- .delay(1000)
- .transform(constant("Bye World"))
- .to("mock:result");
-]]></script>
-</div></div>And then we have the client API where we call the two routes and we can get the responses from both of them. As the code is based on unit test there is a bit of mock in there as well:<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[
-MockEndpoint mock = getMockEndpoint("mock:result");
-// We expect the name job to be faster than the async job even though the async job
-// was started first
-mock.expectedBodiesReceived("Claus", "Bye World");
-
-// Send a async request/reply message to the http endpoint
-Future<Object> future = template.asyncRequestBody("http://0.0.0.0:" + getPort() + "/myservice", "Hello World");
-
-// We got the future so in the meantime we can do other stuff, as this is Camel
-// so lets invoke another request/reply route but this time is synchronous
-String name = template.requestBody("direct:name", "Give me a name", String.class);
-assertEquals("Claus", name);
-
-// Okay we got a name and we have done some other work at the same time
-// the async route is running, but now its about time to wait and get
-// get the response from the async task
-
-// We use the extract future body to get the response from the future
-// (waiting if needed) and then return a string body response.
-// This allows us to do this in a single code line instead of using the
-// JDK Future API to get hold of it, but you can also use that if you want
-// Adding the (String) To make the CS happy
-String response = template.extractFutureBody(future, String.class);
-assertEquals("Bye World", response);
-
-assertMockEndpointsSatisfied();
-]]></script>
-</div></div>All together it should give you the basic idea how to use this <a shape="rect" href="async.html">Async</a> API and what it can do.<h3 id="Async-Example:SynchronousRequestReply">Example: Synchronous Request Reply</h3><p>This example is just to a pure synchronous version of the example from above that was <a shape="rect" href="async.html">Async</a> based.</p><p>The route is the same, so its just how the client initiate and send the messages that differs:</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[
-MockEndpoint mock = getMockEndpoint("mock:result");
-// We expect the http job to complete before the name job
-mock.expectedBodiesReceived("Bye World", "Claus");
-
-// Send a sync request/reply message to the http endpoint
-String response = template.requestBody("http://0.0.0.0:" + getPort() + "/myservice", "Hello World", String.class);
-assertEquals("Bye World", response);
-
-// Send a sync request/reply message to the direct endpoint
-String name = template.requestBody("direct:name", "Give me a name", String.class);
-assertEquals("Claus", name);
-
-assertMockEndpointsSatisfied();
-]]></script>
-</div></div><h3 id="Async-UsingtheAPIwithcallbacks">Using the <a shape="rect" href="async.html">Async</a> API with callbacks</h3><p>Suppose we want to call a <a shape="rect" href="http.html">HTTP</a> service but it is usually slow and thus we do not want to block and wait for the response, but instead let a callback gather the response. This allows us to send multiple requests without waiting for the replies before we can send the next request.</p><p>First we define a route in Camel for the <a shape="rect" href="http.html">HTTP</a> service where we simulate a slow server as it takes at least 1 second to reply.</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[
-// The mocks are here for unit test
-// Simulate a slow http service (delaying a bit) we want to invoke async
-from("jetty:http://0.0.0.0:" + getPort() + "/myservice")
- .delay(300)
- .transform(body().prepend("Hello "))
- .to("mock:result");
-]]></script>
-</div></div>Then we define our callback where we gather the responses. As this is based on an unit test it just gathers the responses in a list. This is a shared callback we use for every request we send in, but you can use your own individual or use an anonymous callback. The callback supports different methods, but we use <strong><code>onDone</code></strong> that is invoked regardless if the <a shape="rect" href="exchange.html">Exchange</a> was processed successfully or failed. The <strong><code>org.apache.camel.spi.Synchronization</code></strong> API provides fine grained methods for <strong><code>onCompletion</code></strong> and <strong><code>onFailure</code></strong> for the two situations.<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[
-/**
- * Our own callback that will gather all the responses.
- * We extend the SynchronizationAdapter class as we then only need to override the onComplete method.
- */
-private static class MyCallback extends SynchronizationAdapter {
-
- // below the String elements are added in the context of different threads so that we should make
- // sure that this's done in a thread-safe manner, that's no two threads should call the data.add()
- // method below concurrently, so why we use Vector here and not e.g. ArrayList
- private final List<String> data = new Vector<String>();
-
- @Override
- public void onComplete(Exchange exchange) {
- // this method is invoked when the exchange was a success and we can get the response
- String body = exchange.getOut().getBody(String.class);
- data.add(body);
-
- // the latch is used for testing purposes
- LATCH.countDown();
- }
-
- public List<String> getData() {
- return data;
- }
-}
-]]></script>
-</div></div>And then we have the client API where we call the <a shape="rect" href="http.html">HTTP</a> service using <strong><code>asyncCallback</code></strong> 3 times with different input. As the invocation is <a shape="rect" href="async.html">Async</a> the client will send 3 requests right after each other, so we have 3 concurrent exchanges in progress. The response is gathered by our callback so we do not have to care how to get the response.<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[
-MyCallback callback = new MyCallback();
-
-// Send 3 async request/reply message to the http endpoint
-// where we let the callback handle gathering the responses
-String url = "http://localhost:" + getPort() + "/myservice";
-template.asyncCallbackRequestBody(url, "Claus", callback);
-template.asyncCallbackRequestBody(url, "Hadrian", callback);
-template.asyncCallbackRequestBody(url, "Willem", callback);
-
-]]></script>
-</div></div><h3 id="Async-UsingtheAPIwiththeCamelclassicAPI">Using the <a shape="rect" href="async.html">Async</a> API with the Camel classic API</h3><p>When using the Camel API to create a producer and send an <a shape="rect" href="exchange.html">Exchange</a> we do it like this:</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[Endpoint endpoint = context.getEndpoint("http://slowserver.org/myservice");
+<div class="wiki-content maincontent"><h2 id="Async-Async">Async</h2><p><strong>Available as of Camel 2.0</strong></p><p>The asynchronous API in Camel have been rewritten for Camel 2.0, and the information on this page applies for Camel 2.0 and later.</p><p>The <a shape="rect" href="async.html">Async</a> API in Camel is primarily divided in two areas:</p><ol><li>Initiating an <a shape="rect" href="async.html">Async</a> messaging from the client</li><li>Turning a route into <a shape="rect" href="async.html">Async</a> using the <strong>threads</strong> <a shape="rect" href="dsl.html">DSL</a></li></ol><p>Before we look at these two areas we start with a bit of background information and looks at the concept from at a higher level using diagrams. Then we check out the first area how a client can initiate an <a shape="rect" href="async.html">Async</a> message exchange and we also throw in the synchronous message exchange in the mix as well so we can compare and distill the difference. An
d finally we turn our attention towards the last area the new <strong>threads</strong> DSL and what it can be used for.</p><h2 id="Async-Background">Background</h2><p>The new <a shape="rect" href="async.html">Async</a> API in Camel 2.0 leverages in much greater detail the Java Concurrency API and its support for executing tasks asynchronous. Therefore the Camel <a shape="rect" href="async.html">Async</a> API should be familiar for users with knowledge of the Java Concurrency API.</p><h3 id="Async-Afewconceptstomaster">A few concepts to master</h3><p>When doing messaging there are a few aspects to keep in mind. First of all a caller can initiate a message exchange as either:</p><ul class="alternate"><li><a shape="rect" href="event-message.html">Request only</a></li><li><a shape="rect" href="request-reply.html">Request Reply</a></li></ul><p><a shape="rect" href="event-message.html">Request only</a> is when the caller sends a message but do <strong>not</strong> expect any reply. This i
s also known as fire and forget or event message. The <a shape="rect" href="request-reply.html">Request Reply</a> is when the caller sends a message and then <strong>waits for a reply</strong>. This is like the <a shape="rect" href="http.html">HTTP</a> protocol that we use every day when we surf the web. We send a request to fetch a web page and wait until the reply message comes with the web content.</p><p>In Camel a message is labeled with a Message <a shape="rect" href="exchange-pattern.html">Exchange Pattern</a> that labels whether its a request only or request reply message. Camel uses the <a shape="rect" href="jbi.html">JBI</a> term for this an uses <strong><code>InOnly</code></strong> for the request only, and <strong><code>InOut</code></strong> for the request reply.</p><p>For all message exchange they can be executed either:</p><ul class="alternate"><li>synchronous</li><li>asynchronous</li></ul><h4 id="Async-SynchronousRequestReply">Synchronous Request Reply</h4><p>A synchr
onous exchange is defined as the caller sends a message and waits until its complete before continuing.</p><p>This is illustrated in the diagram below:</p><p><span class="confluence-embedded-file-wrapper"><img class="confluence-embedded-image" src="async.data/camel_sync_request_reply.png" data-image-src="/confluence/download/attachments/117116/camel_sync_request_reply.png?version=1&modificationDate=1241917552000&api=v2" data-unresolved-comment-count="0" data-linked-resource-id="10641" data-linked-resource-version="1" data-linked-resource-type="attachment" data-linked-resource-default-alias="camel_sync_request_reply.png" data-base-url="https://cwiki.apache.org/confluence" data-linked-resource-content-type="image/png" data-linked-resource-container-id="117116" data-linked-resource-container-version="57"></span></p><ol><li>The client sends a sync <a shape="rect" href="request-reply.html">Request Reply</a> message over <a shape="rect" href="http.html">HTTP</a> to Camel. The clie
nt application will wait for the response that Camel routes and processes.</li><li>The message invokes an external <a shape="rect" href="mina.html">TCP</a> service using synchronous <a shape="rect" href="request-reply.html">Request Reply</a>. The client application still waits for the response.</li><li>The response is send back to the client.</li></ol><h4 id="Async-AsynchronousRequestReply">Asynchronous Request Reply</h4><p>On the other hand the asynchronous version is where the caller sends a message to an <a shape="rect" href="endpoint.html">Endpoint</a> and then returns immediately back to the caller. The message however is processed in another thread, the asynchronous thread. Then the caller can continue doing other work and at the same time the asynchronous thread is processing the message.</p><p>This is illustrated in the diagram below:</p><p><span class="confluence-embedded-file-wrapper"><img class="confluence-embedded-image" src="async.data/camel_async_request_reply.png" dat
a-image-src="/confluence/download/attachments/117116/camel_async_request_reply.png?version=2&modificationDate=1241928088000&api=v2" data-unresolved-comment-count="0" data-linked-resource-id="10640" data-linked-resource-version="2" data-linked-resource-type="attachment" data-linked-resource-default-alias="camel_async_request_reply.png" data-base-url="https://cwiki.apache.org/confluence" data-linked-resource-content-type="image/png" data-linked-resource-container-id="117116" data-linked-resource-container-version="57"></span></p><ol><li>The client sends an <a shape="rect" href="async.html">Async</a><a shape="rect" href="request-reply.html">Request Reply</a> message over <a shape="rect" href="http.html">HTTP</a> to Camel. The control is immediately returned to the client application, that can continue and do other work while Camel routes the message.</li><li>Camel invokes an external <a shape="rect" href="mina.html">TCP</a> service using synchronous <a shape="rect" href="reques
t-reply.html">Request Reply</a>. The client application can do other work simultaneously.</li><li>The client wants to get the reply so it uses the Future handle it got as <em>response</em> from step 1. With this handle it retrieves the reply, wait if necessary if the reply is not ready.</li></ol><p> </p><h4 id="Async-SynchronousRequestOnly">Synchronous Request Only</h4><p> </p><p>You can also do synchronous <a shape="rect" href="event-message.html">Request only</a> with Camel. The client sends a message to Camel in which a reply is not expected. However the client still waits until the message is processed completely.</p><p>This is illustrated in the diagram below:</p><p><span class="confluence-embedded-file-wrapper"><img class="confluence-embedded-image" src="async.data/camel_sync_request_only.png" data-image-src="/confluence/download/attachments/117116/camel_sync_request_only.png?version=1&modificationDate=1241923637000&api=v2" data-unresolved-comment-count="0" d
ata-linked-resource-id="10642" data-linked-resource-version="1" data-linked-resource-type="attachment" data-linked-resource-default-alias="camel_sync_request_only.png" data-base-url="https://cwiki.apache.org/confluence" data-linked-resource-content-type="image/png" data-linked-resource-container-id="117116" data-linked-resource-container-version="57"></span></p><ol><li>The client sends a <a shape="rect" href="event-message.html">Request only</a> and we can still use <a shape="rect" href="http.html">HTTP</a> despite http being <a shape="rect" href="request-reply.html">Request Reply</a> by nature.</li><li>Camel invokes an external <a shape="rect" href="mina.html">TCP</a> service using synchronous <a shape="rect" href="request-reply.html">Request Reply</a>. The client application is still waiting.</li><li>The message is processed completely and the control is returned to the client.</li></ol><p>So why do you want to use synchronous <a shape="rect" href="event-message.html">Request Only
</a>? Well if you want to know whether the message was processed successfully or not before continuing. With synchronous it allows you to wait while the message is being processed. In case the processing was successful the control is returned to the client with no notion of error. In case of failure the client can detect this as an exception is thrown. (and <strong><code>exchange.isFailed()</code></strong> returns <strong><code>true</code>).</strong></p><h3 id="Async-AsynchronousRequestOnly">Asynchronous Request Only</h3><p>As opposed to the synchronous <a shape="rect" href="event-message.html">Request Only</a> the <a shape="rect" href="async.html">Async</a> counter part will <strong>not</strong> wait for the processing of the message to complete. In this case the client can immediately continue doing other work while the message is being routed and processed in Camel.</p><p>This is illustrated in the diagram below:</p><p><span class="confluence-embedded-file-wrapper"><img class="co
nfluence-embedded-image" src="async.data/camel_async_request_only.png" data-image-src="/confluence/download/attachments/117116/camel_async_request_only.png?version=1&modificationDate=1241928107000&api=v2" data-unresolved-comment-count="0" data-linked-resource-id="10644" data-linked-resource-version="1" data-linked-resource-type="attachment" data-linked-resource-default-alias="camel_async_request_only.png" data-base-url="https://cwiki.apache.org/confluence" data-linked-resource-content-type="image/png" data-linked-resource-container-id="117116" data-linked-resource-container-version="57"></span></p><ol><li>The client sends a <a shape="rect" href="event-message.html">Request only</a> and we can still use <a shape="rect" href="http.html">HTTP</a> despite HTTP being <a shape="rect" href="request-reply.html">Request Reply</a> by nature. The control is immediately returned to the client application, that can continue and do other work while Camel routes the message.</li><li>Camel
invokes an external <a shape="rect" href="mina.html">TCP</a> service using synchronous <a shape="rect" href="request-reply.html">Request Reply</a>. The client application can do other work simultaneously.</li><li>The message completes but no result is returned to the client.<br clear="none"><br clear="none"></li></ol><rich-text-body><p><strong>Note:</strong> As Camel always returns a <strong><code>Future</code></strong> handle for <a shape="rect" href="async.html">Async</a> messaging to the client. The client can use this handler to get hold of the status of the processing whether the task is complete or an Exception occurred during processing. Note that the client is not required to do so, its perfect valid to just ignore the Future handle.</p></rich-text-body><parameter ac:name="">Knowing if an Asynchronous Request Only failed</parameter><rich-text-body><p>In case you want to know whether the <a shape="rect" href="async.html">Async</a> <a shape="rect" href="event-message.html">Req
uest Only</a> failed, then you can use the <strong><code>Future</code></strong> handle and invoke <strong><code>get()</code></strong> and if it throws a <strong><code>ExecutionException</code></strong> then the processing failed. The caused exception is wrapped. You can invoke <strong><code>isDone()</code></strong> first to test whether the task is done or still in progress. Otherwise invoking <strong><code>get()</code></strong> will wait until the task is done.</p></rich-text-body><p>With these diagrams in mind lets turn out attention to the <a shape="rect" href="async.html">Async</a> API and how to use it with Camel.</p><h2 id="Async-1)TheClientAPI">1) The <a shape="rect" href="async.html">Async</a> Client API</h2><p>Camel provides the <a shape="rect" href="async.html">Async</a> Client API in the <a shape="rect" class="external-link" href="http://camel.apache.org/maven/current/camel-core/apidocs/org/apache/camel/ProducerTemplate.html">ProducerTemplate</a> where we have added about
ten new methods to Camel 2.0.</p><p>We have listed the most important in the table below:</p><div class="table-wrap"><table class="confluenceTable"><tbody><tr><th colspan="1" rowspan="1" class="confluenceTh"><p>Method</p></th><th colspan="1" rowspan="1" class="confluenceTh"><p>Returns</p></th><th colspan="1" rowspan="1" class="confluenceTh"><p>Description</p></th></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><p><code>setExecutorService</code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p><code>void</code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>Is used to set the Java <strong><code>ExecutorService</code></strong>. Camel will by default provide a <strong><code>ScheduledExecutorService</code></strong> with 5 thread in the pool.</p></td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><p><code>asyncSend</code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p><code>Future<Exchange></code></p></td><td colspan="
1" rowspan="1" class="confluenceTd"><p>Is used to send an async exchange to a Camel <a shape="rect" href="endpoint.html">Endpoint</a>. Camel will immediately return control to the caller thread after the task has been submitted to the executor service. This allows you to do other work while Camel processes the exchange in the other async thread.</p></td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><p><code>asyncSendBody</code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p><code>Future<Object></code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>As above but for sending body only. This is a request only messaging style so no reply is expected. Uses the <strong><code>InOnly</code></strong> exchange pattern.</p></td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><p><code>asyncRequestBody</code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p><code>Future<Object></code></p></td><td colspan="1" rowspan="1" class=
"confluenceTd"><p>As above but for sending body only. This is a <a shape="rect" href="request-reply.html">Request Reply</a> messaging style so a reply is expected. Uses the <strong><code>InOut</code></strong> exchange pattern.</p></td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><p><code>extractFutureBody</code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p><code>T</code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>Is used to get the result from the asynchronous thread using the Java Concurrency Future handle.</p></td></tr></tbody></table></div><p>The <strong><code>asyncSend</code></strong> and <strong><code>asyncRequest</code></strong> methods return a Future handle. This handle is what the caller must use later to retrieve the asynchronous response. You can do this by using the <strong><code>extractFutureBody</code></strong> method, or just use plain Java but invoke <strong><code>get()</code></strong> on the <strong><code>Future</code></s
trong> handle.</p><h3 id="Async-TheClientAPIwithcallbacks">The <a shape="rect" href="async.html">Async</a> Client API with callbacks</h3><p>In addition to the Client API from above Camel provides a variation that uses <a shape="rect" href="oncompletion.html">callbacks</a> when the message <a shape="rect" href="exchange.html">Exchange</a> is done.</p><div class="table-wrap"><table class="confluenceTable"><tbody><tr><th colspan="1" rowspan="1" class="confluenceTh"><p>Method</p></th><th colspan="1" rowspan="1" class="confluenceTh"><p>Returns</p></th><th colspan="1" rowspan="1" class="confluenceTh"><p>Description</p></th></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><p><code>asyncCallback</code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p><code>Future<Exchange></code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>In addition a callback is passed in as a parameter using the <strong><code>org.apache.camel.spi.Synchronization</code></strong>
Callback. The callback is invoked when the message exchange is done.</p></td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><p><code>asyncCallbackSendBody</code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p><code>Future<Object></code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>As above but for sending body only. This is a request only messaging style so no reply is expected. Uses the <strong><code>InOnly</code></strong> exchange pattern.</p></td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><p><code>asyncCallbackRequestBody</code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p><code>Future<Object></code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>As above but for sending body only. This is a <a shape="rect" href="request-reply.html">Request Reply</a> messaging style so a reply is expected. Uses the <strong><code>InOut</code></strong> exchange pattern.</p></td></tr></tbody></table></div><
p>These methods also returns the <strong><code>Future</code></strong> handle in case you need them. The difference is that they invokes the callback as well when the <a shape="rect" href="exchange.html">Exchange</a> is done being routed.</p><h4 id="Async-TheFutureAPI">The Future API</h4><p>The <strong><code>java.util.concurrent.Future</code></strong> API have among others the following methods:</p><div class="table-wrap"><table class="confluenceTable"><tbody><tr><th colspan="1" rowspan="1" class="confluenceTh"><p>Method</p></th><th colspan="1" rowspan="1" class="confluenceTh"><p>Returns</p></th><th colspan="1" rowspan="1" class="confluenceTh"><p>Description</p></th></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><p><code>isDone</code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p><code>boolean</code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>Returns a boolean whether the task is done or not. Will even return <strong><code>true</code></s
trong> if the tasks failed due to an exception thrown.</p></td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><p><code>get()</code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p><code>Object</code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>Gets the response of the task. In case of an exception was thrown the <strong><code>java.util.concurrent.ExecutionException</code></strong> is thrown with the caused exception.</p></td></tr></tbody></table></div><h3 id="Async-Example:AsynchronousRequestReply">Example: Asynchronous Request Reply</h3><p>Suppose we want to call a <a shape="rect" href="http.html">HTTP</a> service but it is usually slow and thus we do not want to block and wait for the response, as we can do other important computation. So we can initiate an <a shape="rect" href="async.html">Async</a> exchange to the <a shape="rect" href="http.html">HTTP</a> endpoint and then do other stuff while the slow <a shape="rect" href="http.html">HTTP<
/a> service is processing our request. And then a bit later we can use the <strong><code>Future</code></strong> handle to get the response from the <a shape="rect" href="http.html">HTTP</a> service. Yeah nice so lets do it:</p><p>First we define some routes in Camel. One for the <a shape="rect" href="http.html">HTTP</a> service where we simulate a slow server as it takes at least 1 second to reply. And then other route that we want to invoke while the <a shape="rect" href="http.html">HTTP</a> service is on route. This allows you to be able to process the two routes simultaneously:<plain-text-body>{snippet:id=e1|lang=java|url=camel/trunk/tests/camel-itest/src/test/java/org/apache/camel/itest/async/HttpAsyncTest.java}</plain-text-body>And then we have the client API where we call the two routes and we can get the responses from both of them. As the code is based on unit test there is a bit of mock in there as well:<plain-text-body>{snippet:id=e2|lang=java|url=camel/trunk/tests/camel-i
test/src/test/java/org/apache/camel/itest/async/HttpAsyncTest.java}</plain-text-body>All together it should give you the basic idea how to use this <a shape="rect" href="async.html">Async</a> API and what it can do.</p><h3 id="Async-Example:SynchronousRequestReply">Example: Synchronous Request Reply</h3><p>This example is just to a pure synchronous version of the example from above that was <a shape="rect" href="async.html">Async</a> based.</p><p>The route is the same, so its just how the client initiate and send the messages that differs:<plain-text-body>{snippet:id=e2|lang=java|url=camel/trunk/tests/camel-itest/src/test/java/org/apache/camel/itest/async/HttpSyncTest.java}</plain-text-body></p><h3 id="Async-UsingtheAPIwithcallbacks">Using the <a shape="rect" href="async.html">Async</a> API with callbacks</h3><p>Suppose we want to call a <a shape="rect" href="http.html">HTTP</a> service but it is usually slow and thus we do not want to block and wait for the response, but instead le
t a callback gather the response. This allows us to send multiple requests without waiting for the replies before we can send the next request.</p><p>First we define a route in Camel for the <a shape="rect" href="http.html">HTTP</a> service where we simulate a slow server as it takes at least 1 second to reply.<plain-text-body>{snippet:id=e1|lang=java|url=camel/trunk/tests/camel-itest/src/test/java/org/apache/camel/itest/async/HttpAsyncCallbackTest.java}</plain-text-body>Then we define our callback where we gather the responses. As this is based on an unit test it just gathers the responses in a list. This is a shared callback we use for every request we send in, but you can use your own individual or use an anonymous callback. The callback supports different methods, but we use <strong><code>onDone</code></strong> that is invoked regardless if the <a shape="rect" href="exchange.html">Exchange</a> was processed successfully or failed. The <strong><code>org.apache.camel.spi.Synchroni
zation</code></strong> API provides fine grained methods for <strong><code>onCompletion</code></strong> and <strong><code>onFailure</code></strong> for the two situations.<plain-text-body>{snippet:id=e2|lang=java|url=camel/trunk/tests/camel-itest/src/test/java/org/apache/camel/itest/async/HttpAsyncCallbackTest.java}</plain-text-body>And then we have the client API where we call the <a shape="rect" href="http.html">HTTP</a> service using <strong><code>asyncCallback</code></strong> 3 times with different input. As the invocation is <a shape="rect" href="async.html">Async</a> the client will send 3 requests right after each other, so we have 3 concurrent exchanges in progress. The response is gathered by our callback so we do not have to care how to get the response.<plain-text-body>{snippet:id=e3|lang=java|url=camel/trunk/tests/camel-itest/src/test/java/org/apache/camel/itest/async/HttpAsyncCallbackTest.java}</plain-text-body></p><h3 id="Async-UsingtheAPIwiththeCamelclassicAPI">Using
the <a shape="rect" href="async.html">Async</a> API with the Camel classic API</h3><p>When using the Camel API to create a producer and send an <a shape="rect" href="exchange.html">Exchange</a> we do it like this:</p><parameter ac:name="language">java</parameter><plain-text-body>Endpoint endpoint = context.getEndpoint("http://slowserver.org/myservice");
Exchange exchange = endpoint.createExchange();
-exchange.getIn().setBody("Order ABC");
+exchange.getIn().setBody("Order ABC");
// create a regular producer
Producer producer = endpoint.createProducer();
// send the exchange and wait for the reply as this is synchronous
producer.process(exchange);
-]]></script>
-</div></div><p>But to do the same with <a shape="rect" href="async.html">Async</a> we need a little help from a helper class, so the code is:</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[Endpoint endpoint = context.getEndpoint("http://slowserver.org/myservice");
+</plain-text-body><p>But to do the same with <a shape="rect" href="async.html">Async</a> we need a little help from a helper class, so the code is:</p><parameter ac:name="language">java</parameter><plain-text-body>Endpoint endpoint = context.getEndpoint("http://slowserver.org/myservice");
Exchange exchange = endpoint.createExchange();
-exchange.getIn().setBody("Order ABC");
+exchange.getIn().setBody("Order ABC");
// create a regular producer
Producer producer = endpoint.createProducer();
@@ -223,28 +102,7 @@ Future<Exchange> future = AsyncPro
// and to get the response we use regular Java Concurrency API
Exchange response = future.get();
-]]></script>
-</div></div><h2 id="Async-2)UsingtheThreadsDSL">2) Using the Threads DSL</h2><p>In Camel 2.0 the <code>threads</code> DSL replaces the old <code>thread</code> DSL.</p><h3 id="Async-Camel2.0to2.3behavior">Camel 2.0 to 2.3 behavior</h3><p>The <code>threads</code> DSL leverages the JDK concurrency framework for multi threading. It can be used to turn a synchronous route into <a shape="rect" href="async.html">Async</a>. What happens is that from the point forwards from <strong><code>threads</code></strong> the messages is routed asynchronous in a new thread. The caller will either wait for a reply if a reply is expected, such as when we use <a shape="rect" href="request-reply.html">Request Reply</a> messaging. Or the caller will complete as well if no reply was expected such as <a shape="rect" href="event-message.html">Request Only</a> messaging.</p><h3 id="Async-FromCamel2.4onbehavior">From Camel 2.4 on behavior</h3><p>The <code>threads</code> DSL leverages the JDK concurrency framewor
k for multi threading. It can be used to turn a synchronous route into <a shape="rect" href="async.html">Async</a>. What happens is that from the point forwards from <strong><code>threads</code></strong> the messages is routed asynchronous in a new thread. Camel leverages the <a shape="rect" href="asynchronous-processing.html">asynchronous routing engine</a>, which was re-introduced in Camel 2.4, to continue routing the <a shape="rect" href="exchange.html">Exchange</a> asynchronously.</p><p>The <code>threads</code> DSL supports the following options:</p><div class="table-wrap"><table class="confluenceTable"><tbody><tr><th colspan="1" rowspan="1" class="confluenceTh"><p>Option</p></th><th colspan="1" rowspan="1" class="confluenceTh">Default</th><th colspan="1" rowspan="1" class="confluenceTh"><p>Description</p></th></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><p><code>poolSize</code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><code>10</code></td><td colspan
="1" rowspan="1" class="confluenceTd"><p>A number to indicate the core pool size of the underlying Java <strong><code>ExecutorService</code></strong> that is actually doing all the heavy lifting of handling <a shape="rect" href="async.html">Async</a> tasks and correlate replies etc.</p></td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><p><code>maxPoolSize</code></p></td><td colspan="1" rowspan="1" class="confluenceTd"> </td><td colspan="1" rowspan="1" class="confluenceTd"><p>A number to indicate the maximum pool size of the of the underlying Java <strong><code>ExecutorService</code></strong></p></td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><p><code>keepAliveTime</code></p></td><td colspan="1" rowspan="1" class="confluenceTd"> </td><td colspan="1" rowspan="1" class="confluenceTd"><p>A number to indicate how long to keep inactive threads alive</p></td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><p><code>timeUnit</code></p></td><td
colspan="1" rowspan="1" class="confluenceTd"> </td><td colspan="1" rowspan="1" class="confluenceTd"><p>Time unit for the <strong><code>keepAliveTime</code></strong> option</p></td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><p><code>maxQueueSize</code></p></td><td colspan="1" rowspan="1" class="confluenceTd"> </td><td colspan="1" rowspan="1" class="confluenceTd"><p>A number to indicate the maximum number of tasks to keep in the worker queue for the underlying Java <strong><code>ExecutorService</code></strong></p></td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><p><code>threadName</code></p></td><td colspan="1" rowspan="1" class="confluenceTd"> </td><td colspan="1" rowspan="1" class="confluenceTd"><p>To use a custom thread name pattern.</p><p>See <a shape="rect" href="threading-model.html">Threading Model</a> for more details.</p></td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><p><code>rejectedPolicy</code></p></td><td colspan
="1" rowspan="1" class="confluenceTd"> </td><td colspan="1" rowspan="1" class="confluenceTd"><p>How to handle rejected tasks.</p><p>The following options are supported:</p><ul><li><strong><code>Abort</code></strong></li><li><strong><code>CallerRuns</code></strong></li><li><strong><code>Discard</code></strong></li><li><strong><code>DiscardOldest</code></strong></li></ul><p>See below for more details.</p></td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><p><code>callerRunsWhenRejected</code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><code>true</code></td><td colspan="1" rowspan="1" class="confluenceTd"><p>A boolean to toggle between the most common rejection policies.</p><ul><li><strong><code>true</code></strong> is the same as <strong><code>rejectedPolicy=CallerRuns</code></strong></li><li><strong><code>false</code></strong> is the same as <strong><code>rejectedPolicy=Abort</code></strong></li></ul></td></tr><tr><td colspan="1" rowspan="1" class="conf
luenceTd"><p><code>executorService</code></p></td><td colspan="1" rowspan="1" class="confluenceTd"> </td><td colspan="1" rowspan="1" class="confluenceTd"><p>You can provide a custom <strong><code>ExecutorService</code></strong> to use, for instance in a managed environment a J2EE container could provide this service so all thread pools is controlled by the J2EE container.</p></td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><code>executorServiceRef</code></td><td colspan="1" rowspan="1" class="confluenceTd"> </td><td colspan="1" rowspan="1" class="confluenceTd"><p>You can provide a named reference to the custom <strong><code>ExecutorService</code></strong> from the Camel registry.</p><p>Keep in mind that reference to the custom executor service cannot be used together with the executor-related options (like <strong><code>poolSize</code></strong> or <strong><code>maxQueueSize</code>) as referenced executor service should be configured already.</strong></p></td>
</tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><p><code>waitForTaskToComplete</code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><code>IfReplyExpected</code></td><td colspan="1" rowspan="1" class="confluenceTd"><p><strong><span style="color: rgb(255,0,0);">@deprecated</span> (removed in Camel 2.4):</strong> Option to specify if the caller should wait for the asynchronous task to be complete or not before continuing.</p><p>The following options are supported:</p><ul><li><strong><code>Always</code></strong></li><li><strong><code>Never</code></strong></li><li><strong><code>IfReplyExpected</code></strong></li></ul><p>The first two options is self explained. The last will only wait if the message is <a shape="rect" href="request-reply.html">Request Reply</a> based.</p></td></tr></tbody></table></div><h4 id="Async-AboutRejectedTasks">About Rejected Tasks</h4><p>The <strong><code>threads</code></strong> DSL uses a thread pool which has a worker queue for tasks.
When the worker queue gets full, the task is rejected. You can customize how to react upon this using the <strong><code>rejectedPolicy</code></strong> and <strong><code>callerRunsWhenRejected</code></strong> option. The latter is used for easily switch between the two most common and recommended settings. Both let the current caller thread execute the task e.g., it will become synchronous, but also give time for the thread pool to process its current tasks, without adding more tasks - sort of self throttling. This is the default behavior.</p><p>If setting <strong><code>callerRunsWhenRejected=false</code></strong> you use the <strong><code>Abort</code></strong> policy, which mean the task is rejected, and a <strong><code>RejectedExecutionException</code></strong> is set on the <a shape="rect" href="exchange.html">Exchange</a>, and the <a shape="rect" href="exchange.html">Exchange</a> will stop continue being routed, and its <strong><code>UnitOfWork</code></strong> will be regarded a
s failed.</p><p>The other options <strong><code>Discard</code></strong> and <strong><code>DiscardOldest</code></strong> works a bit like <strong><code>Abort</code></strong>, however they do <strong>not</strong> set any Exception on the <a shape="rect" href="exchange.html">Exchange</a>, which mean the <a shape="rect" href="exchange.html">Exchange</a> will <strong>not</strong> be regarded as failed, but the <a shape="rect" href="exchange.html">Exchange</a> will be successful. When using <strong><code>Discard</code></strong> and <strong><code>DiscardOldest</code></strong> then the <a shape="rect" href="exchange.html">Exchange</a> will not continue being routed.</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"><p><strong>Note:</strong> there's an issue with these two options in <strong>Camel 2.9</strong> or e
arlier, that cause the <strong><code>UnitOfWork</code></strong> not to be triggered, so we discourage you from using these options in those Camel releases. This has been fixed in <strong>Camel 2.10</strong>.</p></div></div><h3 id="Async-Example:threadsDSL">Example: <code>threads</code> DSL</h3><p>Suppose we receive orders on a JMS queue. Some of the orders expect a reply while other do not (either a <strong><code>JMSReplyTo</code></strong> exists or not). And lets imagine to process this order we need to do some heavy CPU calculation. So how do we avoid the messages that does not expect a reply to block until the entire message is processed? Well we use the <strong><code>threads</code></strong> DSL to turn the route into multi threading asynchronous routing before the heavy CPU task. Then the messages that does not expect a reply can return beforehand. And the messages that expect a reply, well yeah they have to wait anyway. So this can be accomplished like the route below:</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[
-// just a unit test but imaging using your own data format that does complex
-// and CPU heavy processing for decrypting the message
-DataFormat mySecureDataFormat = new StringDataFormat("iso-8859-1");
-
-// list on the JMS queue for new orders
-from("jms:queue:order")
- // do some sanity check validation
- .to("bean:validateOrder")
- .to("mock:validate")
- // use multi threading with a pool size of 20
- // turn the route async as some others do not expect a reply
- // and a few does then we can use the threads DSL as a turning point
- // if the JMS ReplyTo was set then we expect a reply, otherwise not
- // use a pool of 20 threads for the point forward
- .threads(20)
- // do some CPU heavy processing of the message (we simulate and delay just 500 ms)
- .unmarshal(mySecureDataFormat).delay(500).to("bean:handleOrder").to("mock:order");
-]]></script>
-</div></div><div class="confluence-information-macro confluence-information-macro-warning"><p class="title">Transactions and threads DSL</p><span class="aui-icon aui-icon-small aui-iconfont-error confluence-information-macro-icon"></span><div class="confluence-information-macro-body"><p>Mind that when using transactions its often required that the <a shape="rect" href="exchange.html">Exchange</a> is processed entirely in the same thread, as the transaction manager often uses <strong><code>ThreadLocal</code></strong> to store the intermediate transaction status. For instance Spring Transaction does this. So when using <strong><code>threads</code></strong> DSL the <a shape="rect" href="exchange.html">Exchange</a> that is processed in the asynchronous thread cannot participate in the same transaction as the caller thread.</p><p><strong>Note:</strong> this does not apply to the <strong><code>ProducerTemplate</code></strong> Async API as such as the client usually does not participa
te in a transaction. So you can still use the Camel Client Async API and do asynchronous messaging where the processing of the <a shape="rect" href="exchange.html">Exchange</a> is still handled within transaction. It's only the client that submitted the <a shape="rect" href="exchange.html">Exchange</a> that does not participate in the same transaction.</p></div></div><h3 id="Async-SeeAlso">See Also</h3><ul class="alternate"><li><a shape="rect" href="asynchronous-processing.html">Asynchronous Processing</a></li><li><a shape="rect" href="request-reply.html">Request Reply</a></li><li><a shape="rect" href="event-message.html">Request Only</a></li><li><a shape="rect" class="external-link" href="http://davsclaus.blogspot.com/2009/05/on-road-to-camel-20-concurrency-with.html" rel="nofollow">Blog entry on using async for concurrent file processing</a></li><li><a shape="rect" href="seda.html">SEDA</a></li><li><a shape="rect" href="direct.html">Direct</a></li><li><a shape="rect" href="toasync
.html">ToAsync</a> for non blocking <a shape="rect" href="request-reply.html">Request Reply</a></li></ul></div>
+</plain-text-body><h2 id="Async-2)UsingtheThreadsDSL">2) Using the Threads DSL</h2><p>In Camel 2.0 the <code>threads</code> DSL replaces the old <code>thread</code> DSL.</p><h3 id="Async-Camel2.0to2.3behavior">Camel 2.0 to 2.3 behavior</h3><p>The <code>threads</code> DSL leverages the JDK concurrency framework for multi threading. It can be used to turn a synchronous route into <a shape="rect" href="async.html">Async</a>. What happens is that from the point forwards from <strong><code>threads</code></strong> the messages is routed asynchronous in a new thread. The caller will either wait for a reply if a reply is expected, such as when we use <a shape="rect" href="request-reply.html">Request Reply</a> messaging. Or the caller will complete as well if no reply was expected such as <a shape="rect" href="event-message.html">Request Only</a> messaging.</p><h3 id="Async-FromCamel2.4onbehavior">From Camel 2.4 on behavior</h3><p>The <code>threads</code> DSL leverages the JDK concurrency fr
amework for multi threading. It can be used to turn a synchronous route into <a shape="rect" href="async.html">Async</a>. What happens is that from the point forwards from <strong><code>threads</code></strong> the messages is routed asynchronous in a new thread. Camel leverages the <a shape="rect" href="asynchronous-processing.html">asynchronous routing engine</a>, which was re-introduced in Camel 2.4, to continue routing the <a shape="rect" href="exchange.html">Exchange</a> asynchronously.</p><p>The <code>threads</code> DSL supports the following options:</p><div class="table-wrap"><table class="confluenceTable"><tbody><tr><th colspan="1" rowspan="1" class="confluenceTh"><p>Option</p></th><th colspan="1" rowspan="1" class="confluenceTh">Default</th><th colspan="1" rowspan="1" class="confluenceTh"><p>Description</p></th></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><p><code>poolSize</code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><code>10</code></td><td c
olspan="1" rowspan="1" class="confluenceTd"><p>A number to indicate the core pool size of the underlying Java <strong><code>ExecutorService</code></strong> that is actually doing all the heavy lifting of handling <a shape="rect" href="async.html">Async</a> tasks and correlate replies etc.</p></td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><p><code>maxPoolSize</code></p></td><td colspan="1" rowspan="1" class="confluenceTd"> </td><td colspan="1" rowspan="1" class="confluenceTd"><p>A number to indicate the maximum pool size of the of the underlying Java <strong><code>ExecutorService</code></strong></p></td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><p><code>keepAliveTime</code></p></td><td colspan="1" rowspan="1" class="confluenceTd"> </td><td colspan="1" rowspan="1" class="confluenceTd"><p>A number to indicate how long to keep inactive threads alive</p></td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><p><code>timeUnit</code></p></t
d><td colspan="1" rowspan="1" class="confluenceTd"> </td><td colspan="1" rowspan="1" class="confluenceTd"><p>Time unit for the <strong><code>keepAliveTime</code></strong> option</p></td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><p><code>maxQueueSize</code></p></td><td colspan="1" rowspan="1" class="confluenceTd"> </td><td colspan="1" rowspan="1" class="confluenceTd"><p>A number to indicate the maximum number of tasks to keep in the worker queue for the underlying Java <strong><code>ExecutorService</code></strong></p></td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><p><code>threadName</code></p></td><td colspan="1" rowspan="1" class="confluenceTd"> </td><td colspan="1" rowspan="1" class="confluenceTd"><p>To use a custom thread name pattern.</p><p>See <a shape="rect" href="threading-model.html">Threading Model</a> for more details.</p></td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><p><code>rejectedPolicy</code></p></td><td c
olspan="1" rowspan="1" class="confluenceTd"> </td><td colspan="1" rowspan="1" class="confluenceTd"><p>How to handle rejected tasks.</p><p>The following options are supported:</p><ul><li><strong><code>Abort</code></strong></li><li><strong><code>CallerRuns</code></strong></li><li><strong><code>Discard</code></strong></li><li><strong><code>DiscardOldest</code></strong></li></ul><p>See below for more details.</p></td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><p><code>callerRunsWhenRejected</code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><code>true</code></td><td colspan="1" rowspan="1" class="confluenceTd"><p>A boolean to toggle between the most common rejection policies.</p><ul><li><strong><code>true</code></strong> is the same as <strong><code>rejectedPolicy=CallerRuns</code></strong></li><li><strong><code>false</code></strong> is the same as <strong><code>rejectedPolicy=Abort</code></strong></li></ul></td></tr><tr><td colspan="1" rowspan="1" class
="confluenceTd"><p><code>executorService</code></p></td><td colspan="1" rowspan="1" class="confluenceTd"> </td><td colspan="1" rowspan="1" class="confluenceTd"><p>You can provide a custom <strong><code>ExecutorService</code></strong> to use, for instance in a managed environment a J2EE container could provide this service so all thread pools is controlled by the J2EE container.</p></td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><code>executorServiceRef</code></td><td colspan="1" rowspan="1" class="confluenceTd"> </td><td colspan="1" rowspan="1" class="confluenceTd"><p>You can provide a named reference to the custom <strong><code>ExecutorService</code></strong> from the Camel registry.</p><p>Keep in mind that reference to the custom executor service cannot be used together with the executor-related options (like <strong><code>poolSize</code></strong> or <strong><code>maxQueueSize</code>) as referenced executor service should be configured already.</strong></p
></td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><p><code>waitForTaskToComplete</code></p></td><td colspan="1" rowspan="1" class="confluenceTd"><code>IfReplyExpected</code></td><td colspan="1" rowspan="1" class="confluenceTd"><p><strong><span style="color: rgb(255,0,0);">@deprecated</span> (removed in Camel 2.4):</strong> Option to specify if the caller should wait for the asynchronous task to be complete or not before continuing.</p><p>The following options are supported:</p><ul><li><strong><code>Always</code></strong></li><li><strong><code>Never</code></strong></li><li><strong><code>IfReplyExpected</code></strong></li></ul><p>The first two options is self explained. The last will only wait if the message is <a shape="rect" href="request-reply.html">Request Reply</a> based.</p></td></tr></tbody></table></div><h4 id="Async-AboutRejectedTasks">About Rejected Tasks</h4><p>The <strong><code>threads</code></strong> DSL uses a thread pool which has a worker queue for
tasks. When the worker queue gets full, the task is rejected. You can customize how to react upon this using the <strong><code>rejectedPolicy</code></strong> and <strong><code>callerRunsWhenRejected</code></strong> option. The latter is used for easily switch between the two most common and recommended settings. Both let the current caller thread execute the task e.g., it will become synchronous, but also give time for the thread pool to process its current tasks, without adding more tasks - sort of self throttling. This is the default behavior.</p><p>If setting <strong><code>callerRunsWhenRejected=false</code></strong> you use the <strong><code>Abort</code></strong> policy, which mean the task is rejected, and a <strong><code>RejectedExecutionException</code></strong> is set on the <a shape="rect" href="exchange.html">Exchange</a>, and the <a shape="rect" href="exchange.html">Exchange</a> will stop continue being routed, and its <strong><code>UnitOfWork</code></strong> will be rega
rded as failed.</p><p>The other options <strong><code>Discard</code></strong> and <strong><code>DiscardOldest</code></strong> works a bit like <strong><code>Abort</code></strong>, however they do <strong>not</strong> set any Exception on the <a shape="rect" href="exchange.html">Exchange</a>, which mean the <a shape="rect" href="exchange.html">Exchange</a> will <strong>not</strong> be regarded as failed, but the <a shape="rect" href="exchange.html">Exchange</a> will be successful. When using <strong><code>Discard</code></strong> and <strong><code>DiscardOldest</code></strong> then the <a shape="rect" href="exchange.html">Exchange</a> will not continue being routed.</p><rich-text-body><p><strong>Note:</strong> there's an issue with these two options in <strong>Camel 2.9</strong> or earlier, that cause the <strong><code>UnitOfWork</code></strong> not to be triggered, so we discourage you from using these options in those Camel releases. This has been fixed in <strong>Camel 2.10</strong
>.</p></rich-text-body><h3 id="Async-Example:threadsDSL">Example: <code>threads</code> DSL</h3><p>Suppose we receive orders on a JMS queue. Some of the orders expect a reply while other do not (either a <strong><code>JMSReplyTo</code></strong> exists or not). And lets imagine to process this order we need to do some heavy CPU calculation. So how do we avoid the messages that does not expect a reply to block until the entire message is processed? Well we use the <strong><code>threads</code></strong> DSL to turn the route into multi threading asynchronous routing before the heavy CPU task. Then the messages that does not expect a reply can return beforehand. And the messages that expect a reply, well yeah they have to wait anyway. So this can be accomplished like the route below:<plain-text-body>{snippet:id=e1|lang=java|url=camel/trunk/tests/camel-itest/src/test/java/org/apache/camel/itest/async/HttpAsyncDslTest.java}</plain-text-body></p><parameter ac:name="title">Transactions a
nd threads DSL</parameter><rich-text-body><p>Mind that when using transactions its often required that the <a shape="rect" href="exchange.html">Exchange</a> is processed entirely in the same thread, as the transaction manager often uses <strong><code>ThreadLocal</code></strong> to store the intermediate transaction status. For instance Spring Transaction does this. So when using <strong><code>threads</code></strong> DSL the <a shape="rect" href="exchange.html">Exchange</a> that is processed in the asynchronous thread cannot participate in the same transaction as the caller thread.</p><p><strong>Note:</strong> this does not apply to the <strong><code>ProducerTemplate</code></strong> Async API as such as the client usually does not participate in a transaction. So you can still use the Camel Client Async API and do asynchronous messaging where the processing of the <a shape="rect" href="exchange.html">Exchange</a> is still handled within transaction. It's only the client that sub
mitted the <a shape="rect" href="exchange.html">Exchange</a> that does not participate in the same transaction.</p></rich-text-body><h3 id="Async-SeeAlso">See Also</h3><ul class="alternate"><li><a shape="rect" href="asynchronous-processing.html">Asynchronous Processing</a></li><li><a shape="rect" href="request-reply.html">Request Reply</a></li><li><a shape="rect" href="event-message.html">Request Only</a></li><li><a shape="rect" class="external-link" href="http://davsclaus.blogspot.com/2009/05/on-road-to-camel-20-concurrency-with.html" rel="nofollow">Blog entry on using async for concurrent file processing</a></li><li><a shape="rect" href="seda.html">SEDA</a></li><li><a shape="rect" href="direct.html">Direct</a></li><li><a shape="rect" href="toasync.html">ToAsync</a> for non blocking <a shape="rect" href="request-reply.html">Request Reply</a></li></ul></div>
</td>
<td valign="top">
<div class="navigation">
Modified: websites/production/camel/content/bam.html
==============================================================================
--- websites/production/camel/content/bam.html (original)
+++ websites/production/camel/content/bam.html Fri Aug 25 08:22:01 2017
@@ -36,17 +36,6 @@
<![endif]-->
- <link href='//camel.apache.org/styles/highlighter/styles/shCoreCamel.css' rel='stylesheet' type='text/css' />
- <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 src='//camel.apache.org/styles/highlighter/scripts/shBrushPlain.js' type='text/javascript'></script>
-
- <script type="text/javascript">
- SyntaxHighlighter.defaults['toolbar'] = false;
- SyntaxHighlighter.all();
- </script>
<title>
Apache Camel: BAM
@@ -102,26 +91,7 @@
<p>The following example shows how to perform some time based rules on a simple business process of 2 activities - A and B - which correspond with Purchase Orders and Invoices in the example above. If you would like to experiment with this scenario, you may edit this <a shape="rect" class="external-link" href="http://svn.apache.org/repos/asf/camel/trunk/components/camel-bam/src/test/java/org/apache/camel/bam/BamRouteTest.java">Test Case</a>, which defines the activities and rules, and then tests that they work.</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[
-return new ProcessBuilder(entityManagerFactory, transactionTemplate) {
- public void configure() throws Exception {
-
- // let's define some activities, correlating on an XPath on the message bodies
- ActivityBuilder a = activity("seda:a").name("a")
- .correlate(xpath("/hello/@id"));
-
- ActivityBuilder b = activity("seda:b").name("b")
- .correlate(xpath("/hello/@id"));
-
- // now let's add some rules
- b.starts().after(a.completes())
- .expectWithin(seconds(1))
- .errorIfOver(seconds(errorTimeout)).to("mock:overdue");
- }
-};
-]]></script>
-</div></div>
+<plain-text-body>{snippet:id=example|lang=java|url=camel/trunk/components/camel-bam/src/test/java/org/apache/camel/bam/BamRouteTest.java}</plain-text-body>
<p>As you can see in the above example, we first define two activities, and then rules to specify when we expect them to complete for a process instance and when an error condition should be raised.p. The ProcessBuilder is a <a shape="rect" href="routebuilder.html">RouteBuilder</a> and can be added to any <a shape="rect" href="camelcontext.html">CamelContext</a>. </p>