...
The Request Reply is when the caller sends a message and then waits for a reply. This is like the Http HTTP 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.
...
1. The client sends a sync Request Reply message over Http HTTP to Camel. The client application will wait for the response that Camel routes and processes.
2. The message invokes an external TCP service using synchronous Request Reply. The client application still waits for the response.
3. The response is send back to the client.
...
1. The client sends an Async Request Reply message over Http HTTP to Camel. The control is immediately returned to the client application, that can continue and do other work while Camel routes the message.
2. Camel invokes an external TCP service using synchronous Request Reply. The client application can do other work simultaneously.
3. The client wants to get the reply so it uses the Future handle it got as response from step 1. With this handle it retrieves the reply, wait if nessasary if the reply is not ready.
...
1. The client sends a Request only and we can still use Http HTTP despite http being Request Reply by nature.
2. Camel invokes an external TCP service using synchronous Request Reply. The client application is still waiting.
3. The message is processed completely and the control is returned to the client.
...
1. The client sends a Request only and we can still use Http HTTP despite http being Request Reply by nature. The control is immediately returned to the client application, that can continue and do other work while Camel routes the message.
2. Camel invokes an external TCP service using synchronous Request Reply. The client application can do other work simultaneously.
3. The message completes but no result is returned to the client.
...
Suppose we want to call a Http HTTP 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 Async exchange to the Http HTTP endpoint and then do other stuff while the slow Http HTTP service is processing our request. And then a bit later we can use the Future handle to get the response from the Http HTTP service. Yeah nice so lets do it:
First we define some routes in Camel. One for the Http HTTP 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 Http HTTP service is on route. This allows you to be able to process the two routes simultaneously:
...
Suppose we want to call a Http HTTP 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.
First we define a route in Camel for the Http HTTP service where we simulate a slow server as it takes at least 1 second to reply.
...
And then we have the client API where we call the Http HTTP service using asyncCallback 3 times with different input. As the invocation is Async 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.
...
When using the Camel API to create a producer and send an Exchange we do it like this:
![]() 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();
// send the exchange and wait for the reply as this is synchronous
producer.process(exchange);
|
But to do the same with Async we need a little help from a helper class, so the code is:
![]() 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();
|
...
| Option |
Description |
| poolSize |
A number to indicate the core pool size of the underlying Java ExecutorService that is actually doing all the heavy lifting of handling Async tasks and correlate replies etc. By default a pool size of 10 is used. |
| maxPoolSize |
A number to indicate the maximum pool size of the of the underlying Java ExecutorService |
| keepAliveTime |
A number to indicate how long to keep inactive threads alive |
| timeUnit |
Time unit for the keepAliveTime option |
| maxQueueSize |
A number to indicate the maximum number of tasks to keep in the worker queue for the underlying Java ExecutorService |
| threadName |
To use a custom thread name pattern. See Threading Model for more details. |
| rejectedPolicy |
How to handle rejected tasks. Can be either Abort, CallerRuns, Discard, or DiscardOldest. See below for more details. |
| callerRunsWhenRejected |
A boolean to more easily configure between the most common rejection policies. This option is default enabled. true is the same as rejectedPolicy=CallerRuns, and false is the same as rejectedPolicy=Abort. |
| executorService |
You can provide a custom ExecutorService 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. |
| executorServiceRef |
You can provide a named reference to the custom ExecutorService from the Camel registry. Keep in mind that reference to the custom executor service cannot be used together with the executor-related options (like poolSize or maxQueueSize) as referenced executor service should be configured already. |
| waitForTaskToComplete |
@deprecated (removed in Camel 2.4): 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, Never 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. |
...
Async 