Threads
Options
The Threads eip supports 10 options, which are listed below.
Name | Description | Default | Type |
---|---|---|---|
executorServiceRef | To refer to a custom thread pool or use a thread pool profile (as overlay). | String | |
poolSize | Sets the core pool size. | Integer | |
maxPoolSize | Sets the maximum pool size. | Integer | |
keepAliveTime | Sets the keep alive time for idle threads. | Long | |
timeUnit | Sets the keep alive time unit. By default SECONDS is used. Enum values:
| TimeUnit | |
maxQueueSize | Sets the maximum number of tasks in the work queue. <p/> Use <tt>-1 or <tt>Integer.MAX_VALUE for an unbounded queue. | Integer | |
allowCoreThreadTimeOut | Whether idle core threads are allowed to timeout and therefore can shrink the pool size below the core pool size <p/> Is by default <tt>false. | Boolean | |
threadName | Sets the thread name to use. | Threads | String |
rejectedPolicy | Sets the handler for tasks which cannot be executed by the thread pool. Enum values:
| ThreadPoolRejectedPolicy | |
callerRunsWhenRejected | Whether or not to use as caller runs as <b>fallback when a task is rejected being added to the thread pool (when its full). This is only used as fallback if no rejectedPolicy has been configured, or the thread pool has no configured rejection handler. <p/> Is by default <tt>true. | true | String |
description | Sets the description of this node. | DescriptionDefinition |
About rejected tasks
The Threads EIP 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 to easily switch between the two most common and recommended settings. Either let the current caller thread execute the task (i.e. it will become synchronous), but also give time for the thread pool to process its current tasks, without adding more tasks (self throttling). This is the default behavior. If setting callerRunsWhenRejected
you use the Abort
policy, which means 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
work a bit like Abort
, however they do not set any exception on the Exchange, which means 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.