THIS IS A TEST INSTANCE. ALL YOUR CHANGES WILL BE LOST!!!!
...
Option | Description |
|---|---|
poolSize | A number to indicate the core pool size of the underlying Java |
maxPoolSize | A number to indicate the maximum pool size of the of the underlying Java |
keepAliveTime | A number to indicate how long to keep inactive threads alive |
timeUnit | Time unit for the |
maxQueueSize | A number to indicate the maximum number of tasks to keep in the worker queue for the underlying Java |
threadName | To use a custom thread name pattern. See Threading Model for more details. |
rejectedPolicy | How to handle rejected tasks. Can be either |
callerRunsWhenRejected | A boolean to more easily configure between the most common rejection policies. This option is default enabled. |
executorService | You can provide a custom |
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. |
About rejected tasks
The threads 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 rejectedPolicy and callerRunsWhenRejected option. The latter is used for easily switch between the two most common and recommended settings. Either let the current caller thread execute the task (eg 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. If setting callerRunsWhenRejected you use the Abort policy, which mean the task is rejected, and a RejectedExecutionException is set on the Exchange, and the Exchange will stop continue being routed, and its UnitOfWork will be regarded as failed.
The other options Discard and DiscardOldest works a bit like Abort, however they do not set any Exception on the Exchange, which mean the Exchange will not be regarded as failed, but the Exchange will be successful. When using Discard and DiscardOldest then the Exchange will not continue being routed. Notice: There is a issue with these two options in Camel 2.9 or below, that cause the UnitOfWork not to be triggered, so we discourage you from using these options in those Camel releases. This has been fixed in Camel 2.10 onwards.
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 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:
...