WildFly Threads Subsystem Concepts: Difference between revisions
| (9 intermediate revisions by the same user not shown) | |||
| Line 2: | Line 2: | ||
* [[WildFly Threads Subsystem#Subjects|WildFly Threads Subsystem]] | * [[WildFly Threads Subsystem#Subjects|WildFly Threads Subsystem]] | ||
=Executor Model= | |||
Thread pools defined by the "threads" subsystem can be shared between WildFly components that are compatible with the ''executor model''. An example of such components are [[#How_Does_it_Relate_to_JBossWeb.3F|JBoss Web connectors]]. | |||
An ''executor'' is an asynchronous execution mechanism capable of executing tasks in the background. The terms "executor" and "thread pool" are equivalent in this context and can be used interchangeably. Also see [[java.util.concurrent Executors]]. There are six built-in executor types: | |||
1. '''unbounded-queue-thread-pool'''. This type of thread pool always accepts tasks for execution: if less than the maximum number of threads are running, a new thread is created and associated with a newly submitted tasks. If the maximum number of threads has been reached and all threads are engaged processing tasks, the task is placed into an inbound FIFO queue to be executed when the thread becomes available. | |||
2. '''bounded-queue-thread-pool'''. This type of thread pool maintains a fixed-length queue where tasks that cannot be associated with a thread go, and two pool sizes: a core size and a maximum size. When a task is accepted, if the number of running pool threads is less than the core size, a new thread is started to execute the task. If space remains in the queue, the task is placed in the queue. If the number of running pool threads is less than the maximum size, a new thread is started to execute the task. If blocking is enabled on the executor, the calling thread will block until space becomes available in the queue. The task is delegated to the handoff executor, if a handoff executor is configured. Otherwise, the task is rejected. | |||
3. '''blocking-bounded-queue-thread-pool'''. A thread pool executor with a bounded queue where threads submittings tasks may block. Such a thread pool has a core and maximum size and a specified queue length. When a task is submitted, if the number of running threads is less than the core size, a new thread is created. Otherwise, if there is room in the queue, the task is enqueued. Otherwise, if the number of running threads is less than the maximum size, a new thread is created. Otherwise, the caller blocks until room becomes available in the queue. | |||
4. '''queueless-thread-pool'''. Sometimes, a simple thread pool is required to run tasks in separate threads, reusing threads as they complete their tasks with no intervening queue. This type of pool is ideal for handling tasks which are long-running, perhaps utilizing blocking I/O, since tasks are always started immediately upon acceptance rather than accepting a task and then delaying its execution until other running tasks have completed. | |||
5. '''blocking-queueless-thread-pool'''. A thread pool executor with no queue where threads submittings tasks may block. When a task is submitted, if the number of running threads is less than the maximum size, a new thread is created. Otherwise, the caller blocks until another thread completes its task and accepts the new one. | |||
6. '''scheduled-thread-pool'''. This is a special type of executor whose purpose is to execute tasks at specific times and time intervals, based on the <tt>java.util.concurrent.ScheduledThreadPoolExecutor</tt> class. | |||
An executor needs a ''thread factory'', that instantiates the threads required by the executor. The thread factory defines the thread name pattern, the thread priority and the thread group name. The thread factory must be defined within the subsystem configuration and referred to from within the executor definition. | |||
For details on how to configure an executor and its associated thread factory, see: | |||
<blockquote style="background-color: #f9f9f9; border: solid thin lightgrey;"> | |||
:[[WildFly Threads Subsystem Configuration]] | |||
</blockquote> | |||
=How Does it Relate to JBossWeb?= | =How Does it Relate to JBossWeb?= | ||
Latest revision as of 21:27, 8 June 2016
Internal
Executor Model
Thread pools defined by the "threads" subsystem can be shared between WildFly components that are compatible with the executor model. An example of such components are JBoss Web connectors.
An executor is an asynchronous execution mechanism capable of executing tasks in the background. The terms "executor" and "thread pool" are equivalent in this context and can be used interchangeably. Also see java.util.concurrent Executors. There are six built-in executor types:
1. unbounded-queue-thread-pool. This type of thread pool always accepts tasks for execution: if less than the maximum number of threads are running, a new thread is created and associated with a newly submitted tasks. If the maximum number of threads has been reached and all threads are engaged processing tasks, the task is placed into an inbound FIFO queue to be executed when the thread becomes available.
2. bounded-queue-thread-pool. This type of thread pool maintains a fixed-length queue where tasks that cannot be associated with a thread go, and two pool sizes: a core size and a maximum size. When a task is accepted, if the number of running pool threads is less than the core size, a new thread is started to execute the task. If space remains in the queue, the task is placed in the queue. If the number of running pool threads is less than the maximum size, a new thread is started to execute the task. If blocking is enabled on the executor, the calling thread will block until space becomes available in the queue. The task is delegated to the handoff executor, if a handoff executor is configured. Otherwise, the task is rejected.
3. blocking-bounded-queue-thread-pool. A thread pool executor with a bounded queue where threads submittings tasks may block. Such a thread pool has a core and maximum size and a specified queue length. When a task is submitted, if the number of running threads is less than the core size, a new thread is created. Otherwise, if there is room in the queue, the task is enqueued. Otherwise, if the number of running threads is less than the maximum size, a new thread is created. Otherwise, the caller blocks until room becomes available in the queue.
4. queueless-thread-pool. Sometimes, a simple thread pool is required to run tasks in separate threads, reusing threads as they complete their tasks with no intervening queue. This type of pool is ideal for handling tasks which are long-running, perhaps utilizing blocking I/O, since tasks are always started immediately upon acceptance rather than accepting a task and then delaying its execution until other running tasks have completed.
5. blocking-queueless-thread-pool. A thread pool executor with no queue where threads submittings tasks may block. When a task is submitted, if the number of running threads is less than the maximum size, a new thread is created. Otherwise, the caller blocks until another thread completes its task and accepts the new one.
6. scheduled-thread-pool. This is a special type of executor whose purpose is to execute tasks at specific times and time intervals, based on the java.util.concurrent.ScheduledThreadPoolExecutor class.
An executor needs a thread factory, that instantiates the threads required by the executor. The thread factory defines the thread name pattern, the thread priority and the thread group name. The thread factory must be defined within the subsystem configuration and referred to from within the executor definition.
For details on how to configure an executor and its associated thread factory, see: