WildFly Threads Subsystem Concepts

From NovaOrdis Knowledge Base
Jump to navigation Jump to search

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:

WildFly Threads Subsystem Configuration

How Does it Relate to JBossWeb?

JBossWeb Threading Model

How Does it Relate to Undertow?

Undertow Threading Model

How Does it Relate to Remoting?

Remoting Threading Model

How Does it Relate to HornetQ?

HornetQ Threading Model

How Does it Relate to EJB?