Task executor
Responsible for executing tasks.
(Advanced)
The executor created is a ThreadPoolTaskExecutor. Each submitted task is executed using one of possibly several pooled threads. The behaviour of the executor is specified by the core and max size of the thread pool and the queue size.
When a task is submitted, the executor will first try to use a free thread if the number of active threads is currently less than the core size. If the core size has been reached, then the task will be added to the queue as long as its capacity has not yet been reached. Only then, if the queue's capacity has been reached, will the executor create a new thread beyond the core size. If the max size has also been reached, then the executor will reject the task.
Use the id 'taskScheduler' to define the default task scheduler for this configuration. If this scheduler not is specified, a default scheduler will be created.
Pool size
Specifies the number of different tasks executed at the same time by this executor.
Default when empty: '1-Integer.MAX_VALUE'
(Advanced description) Specifies the core and the maximum thread pool size in order to limit the number of concurrent tasks.
If a single value is provided then the executor will have a fixed-size thread pool (the core and max sizes are the same). It also accepts a range in the form of "min-max".
Eg.: 5-10
Queue capacity
Queue capacity for the executor.
By default, the queue is unbounded, but this is rarely the desired configuration, because it can lead to OutOfMemoryErrors if enough tasks are added to that queue while all pool threads are busy. Furthermore, if the queue is unbounded, then the max size has no effect at all. Since the executor will always try the queue before creating a new thread beyond the core size, a queue must have a finite capacity for the thread pool to grow beyond the core size (this is why a fixed size pool is the only sensible case when using an unbounded queue).
Default when not specified: Integer.MAX_VALUE
Keep alive
Keep-alive time in seconds.
Inactive threads that have been created beyond the core size will timeout after the specified number of seconds elapse. If the executor has an unbounded queue capacity and a size range represented as 0-n, then the core threads will also be configured to timeout when inactive. Otherwise, core threads will never timeout.
Rejection policy
Specifies the behaviour of the executor when a task is rejected.
The following pollicies are applied when a task is rejected: 1. Abort (Default) The executor will throw a TaskRejectedException. 2. Caller runs The executor will force the thread that is calling the submit method to run the task itself. 3. Discard Discard the rejected task silently. 4. Discard the oldest. Discard the oldest unhandled task request.
Usage For applications where some tasks can be skipped under heavy load, either the Discard Policy or Discard Oldest Policy may be configured instead. Another option that works well for applications that need to throttle the submitted tasks under heavy load is the Caller Runs Policy. Instead of throwing an exception or discarding tasks, that policy will simply force the thread that is calling the submit method to run the task itself. The idea is that such a caller will be busy while running that task and not able to submit other tasks immediately. Therefore it provides a simple way to throttle the incoming load while maintaining the limits of the thread pool and queue. Typically this allows the executor to "catch up" on the tasks it is handling and thereby frees up some capacity on the queue, in the pool, or both.
Id
Name that uniquely identifies this flow component.
Required