THIS IS A TEST INSTANCE. ALL YOUR CHANGES WILL BE LOST!!!!
...
The Async API in Camel is primarily divided in two areas
1. Initiating an Async messaging from the client
2. Turning a route into Async using the threads DSL
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 Async message exchange and we also throw in the synchronous message exchange in the mix as well so we can compare and distill the difference.
And finally we turn our attention towards the last area the new async DSL and what it can be used for.
...
| Code Block | ||||
|---|---|---|---|---|
| ||||
Endpoint endpoint = context.getEndpoint("http://slowserver.org/myservice");
Exchange exchange = endpoint.createExchange();
exchange.getIn().setBody("Order ABC");
// create a regular producer
Producer producer = endpoint.createProducer();
// normally you will use a shared exectutor service with pools
ExecutorService executor = Executors.newSingleThreadExecutor();
// send it async with the help of this helper
Future<Exchange> future = AsyncProcessorHelper.asyncProcess(executor, producer, exchange);
// here we got the future handle and we can do other stuff while the exchange is being routed in the other asynchronous thread
...
// and to get the response we use regular Java Concurrency API
Exchange response = future.get();
|
2) Using the
...
Threads DSL
In Camel 2.0 the async threads DSL replaces the old thread DSL.
The async DSL threads DSL leverages the JDK concurrency framework for multi threading. It can be used to turn a synchronous route into Async. What happens is that from the point forwards from async threads 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 Request Reply messaging. Or the caller will complete as well if no reply was expected such as Request Only messaging.
The async threads DSL allows a supports the following options:
Option | Description |
|---|---|
poolSize | A number to indicate the core pool size of the underlying Java |
executorService | You can provide a custom |
waitForTaskToComplete | Option to specify if the caller should wait for the async task to be complete or not before continuing. The following 3 options is supported: Always, Newer or IfReplyExpected. The first two options is self explained. The last will only wait if the message is Request Reply based. The default option is IfReplyExpected. |
Example:
...
threads DSL
Suppose we receive orders on a JMS queue. Some of the orders expect a reply while other do not (either a JMSReplyTo 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 async threads 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:
...
| Warning | ||
|---|---|---|
| ||
Mind that when using transactions its often required that the Exchange is processed entirely in the same thread, as the transaction manager often uses Notice: This does not apply to the |
...