Thread Pool
This chapter describes the structure and configuration of thread pools.
1. Overview
In a web engine, thread pools are required to handle incoming requests.
A thread pool can be configured at different levels of the web application architecture, such as Web Connection, Virtual Host, and Context. Each level has its own priority level, allowing requests to be processed in separate thread pools.
To utilize all three thread pools, you need to return to the selector. Here, you need to configure the AJP, HTTP, and TCP listeners for server listeners and the use-nio setting for the WebtoB connector as true. If the use-nio setting for the WebtoB and Tmax connectors are set to false, requests are handled only in the Web Connection level thread pool.
The Context and Virtual Host level thread pools are optional, while the Web Connection level thread pool is a mandatory setting. The Context thread pool can be configured in jeus-web-dd.xml, and Virtual Host and Web Connection level thread pools are configured under <virtual-host> and <web-connections> respectively in domain.xml.
|
In versions prior to JEUS 21, each Web Connection in the web engine had its own dedicated thread pool. In JEUS 21 Fix#0, AJP, HTTP, and TCP Web Connections with server listeners were processed independently in different thread pools, which were specifically allocated at the Web Container, Virtual Host, and Context levels. In addition, the WebtoB and Tmax connectors had their own dedicated thread pools for request processing. |
2. Basic Structure
This section provides an overview of the generation, expiration, and utilization of each level of thread pools (Web Connection, Virtual Host, and Context).
The Web Connection level thread pool is created during the startup of the web engine or when a web connection is dynamically added. It serves as the default thread pool for processing incoming requests if neither the Context nor Virtual Host level thread pools exist.
The Virtual Host level thread pool is generated for each virtual host during the web engine’s startup or when a virtual host is dynamically added, provided that there is a configuration for the thread pool in place. Note that the system host, which is responsible for system applications and the default host do not generate thread pools.
The Context level thread pool is created when an application is deployed with the thread pool configuration. At the Context level, unlike the other levels, multiple thread pools can be created. A Context level thread pool can configure one base thread pool and one or more service group thread pools. A service group thread pool can have multiple comma-separated URIs for processing requests targeted at specific URIs, allowing efficient resources utilization based on the incoming request load for each specific URI.
If a specific URI does not have a mapped service group thread pool, the requests for that URI will be directed to the base thread pool, provided that this is configured. If neither the base thread pool is available, the Virtual Host or the Web Connection level, which is the default thread pool, will handle those requests.
When the application is undeployed, all the associated thread pools are expired.
3. Configuration
This section describes how to configure thread pools of each level.
The Web Connection level thread pool must be configured in the domain.xml file. If it is not configured, JEUS cannot successfully start up.
<web-connections>
<http-listener>
<thread-pool>
<min>10</min>
<max>40</max>
<max-idle-time>300000</max-idle-time>
<max-queue>30</max-queue>
</thread-pool>
</http-listener>
</web-connections>As shown in the above example, a Web Connection thread pool can be configured for each listener or connector defined under <web-connections> in the xml file. The Web Connection thread pool is the default thread pool if neither the Context nor Virtual Host level thread pool is specified.
In addition, a thread pool must be configured when a web connection is dynamically added from the jeusadmin console. For more information, see Adding the AJP Listener.
The Virtual Host level thread pool is configured in domain.xml. It is optional, and if not configured, the Web Connection level thread pool handles the requests.
<web-engine>
<virtual-host>
<virtual-host-name>testHost</virtual-host-name>
<host-name>192.1.1.1</host-name>
<thread-pool>
<min>10</min>
<max>20</max>
<max-idle-time>300000</max-idle-time>
<max-queue>30</max-queue>
</thread-pool>
</virtual-host>
</web-engin>As shown in the above example, one Virtual Host thread pool can be configured under <virtual-host>. If no Context level thread pool is available, requests will be directed to the Virtual Host thread pool, and if neither the Virtual Host thread pool is configured, all incoming requests will be directed to the Web Connection thread pool.
The thread pool can also be configured when dynamically adding a virtual host from the jeusadmin console. For more information, see Configuring Virtual Hosts.
The Context level thread pool is configured in jeus-web-dd.xml. It is optional, and if not configured, the Virtual Host level thread pool handles the requests.
<jeus-web-dd>
<thread-pool>
<base>
<name>baseThreadPool</name>
<min>30</min>
<max>50</max>
<max-idle-time>300000</max-idle-time>
<max-queue>30</max-queue>
</base>
<service-group>
<name>service1</name>
<uri>/index.html,/index.jsp</uri>
<min>10</min>
<max>20</max>
<max-idle-time>300000</max-idle-time>
<max-queue>30</max-queue>
</service-group>
<service-group>
<name>service2</name>
<uri>/mostRequestedResource</uri>
<min>10</min>
<max>20</max>
<max-idle-time>300000</max-idle-time>
<max-queue>30</max-queue>
</service-group>
</thread-pool>
</jeus-web-dd>As shown in the above example for the Context level thread pool, one base thread pool and one or more service-group thread pools can be configured under <jeus-web-dd>. To delimit multiple context thread pools, a unique name must be specified for each thread pool. If the requested URI is mapped to the URI configured for one of the service-groups, that service-group thread pool handles the request. Otherwise, the request is directed to the base thread pool. If neither the base thread pool is configured, the request is re-directed to the Virtual Host level thread pool.
When deploying an application through jeusadmin, a single Context thread pool can be added. For more information, refer to deploy-application in JEUS Reference Guide.
-
Common Settings for Thread Pool
-
Worker thread pools have common setting items.
-
The following describes each setting item.
Item Description Min
Minimum number of worker threads to be managed in the pool.
Max
Maximum number of worker threads to be managed in the pool.
Maximum Idle Time
Maximum amount of time during which a thread remains unused before being removed from the pool.
Max Queue
Maximum number of threads to be queued.
Thread State Notify
Notification for a blocked worker thread.
Each thread pool contains the Thread State Notify setting which defines the action to be taken when a failure occurs. For more information about this setting, refer to Configuring Automatic Thread Pool State Management (Thread State Notify).
-
4. Configuring Automatic Thread Pool State Management (Thread State Notify)
Thread State Notify defines the minimum number of worker threads under specific failed conditions to send an emain notification or to recommend a server restart.
The following describes the process of configuring thread state notification in the console tool. When the configuration is complete, you can receive the desired notification for a thread state change in the thread pool.
Once automatic thread pool management is set up, worker threads are managed based on the value specified in 'Max Thread Active Time'. Starting from the point in time when the request processing is initiated, all threads that exceed the specified Max Thread Active Time will be treated and managed as blocked threads.
If the email notifier is used, refer to the "SMTP Handler" section in Logging Configuration for email notification settings.
<web-engine>
<web-connections>
<http-listener>
<thread-pool>
...
<thread-state-notify>
<max-thread-active-time>10000</max-thread-active-time>
<interrupt-thread>false</interrupt-thread>
<active-timeout-notification>false</active-timeout-notification>
<notify-threshold-ratio>0.1</notify-threshold-ratio>
<notify-subject>Notify-Subject</notify-subject>
<restart-threshold-ratio>0.1</restart-threshold-ratio>
<restart-subject>Restart-Subject</restart-subject>
</thread-state-notify>
</thread-pool>
</http-listener>
</web-connections>
</web-engine>The following describes each setting item.
| Item | Description |
|---|---|
Max Thread Active Time |
Maximum amount of time during which a worker thread remains active before being blocked. This duration begins upon the start of the requested service by the worker thread (servlet being executed). It expires when the time period is exceeded or the thread is freed up and returns to the thread pool (thread is no longer blocked). If set to 0 or a negative value, this setting is ignored. |
Notify Threshold Ratio |
Maximum ratio of blocked threads in the total number of threads. If this threshold is reached, it is determined that an error condition has occurred, and thereby an email notification is triggered and sent via the email notifier. Set the value to a decimal point that is smaller than 1. If set to 0 or a negative value, this setting is ignored. |
Restart Threshold Ratio |
Maximum ratio of blocked threads in the total number of threads. If this threshold is reached, it is determined that an error condition has occurred, and thereby an email notification is triggered and sent via the email notifier. After that, a message recommending a server restart is logged in the server log. Set the value to a decimal point that is smaller than 1. If set to 0 or a negative value, this setting is ignored. |
Notify Subject |
Used for sending a warning email. |
Restart Subject |
Used for an engine logging or notification email. |
Interrupt Thread |
Option to trigger an interruption when a worker thread continues to execute a request after expiration of the Max Thread Active Time, which is the active timeout.
|
Active Timeout Notification |
Option to send an email notification for active timeout.
|
|
To configure an SMTP handler for the logger to receive email notifications, specify the name as "jeus.servlet.threadpool.notify" for separate management. |
5. Rules
The following rules are applied when configuring a thread pool.
-
Using the Context and Virtual Host level thread pools requires identification between context and host by reading the request, prior to the thread pool execution.
The corresponding web connections include the HTTP, AJP13, and TCP listeners, which can reference server listeners, and the WebtoB connector with the use-nio setting as true. If use-nio for the WebtoB and Tmax connectors is set to false, these connectors use only the Web Connection level thread pool.
-
To be Noted when configuring WebtoB
Configuring a WebtoB connector requires attention to thread pool configurations depending on the use-nio setting. If use-nio is true, the number of connections is no longer related to threads, and therefore an appropriate value can be set according to the tuning. If use-nio is false, on the other hand, the minimum and maximum values of connection-count must match those of thread-pool. Otherwise, server startup fails.
-
When configuring service group thread pools, ensure that duplicate URIs are not used in different service groups. A URI must start with '/'. According to the servlet specifications, a URI corresponds to the servlet path and path information after the context path.
-
A URI path can include subdirectories. For example, if you specify /myServlet/ as the URI for a service group, incoming requests sent to /testContext/myServlet/servlet1 and /testContext/myServlet/servlet2 are both processed by the same service group with the /myServlet/ URI setting.
-
If multiple service groups are configured, choose the most matched URI.
For example, The URI for Service Group1 is specified as /myServlet/ and Service Group2 as /myServlet/servlet2, incoming requests sent to /testContext/myServlet/servlet1 are handled in Service Group1, and those sent to /testContext/myServlet/servlet2 are processed in Service Group2.
-
Determining which thread pools will handle which requests is simple:
-
Determine whether a web connection that has received a request can use either the Context or Virtual Host thread pool. If neither of those thread pools is available, the request will be handled by the thread pool of the web connection itself.
-
Check whether the context that matches the request contains thread pools. If service group thread pools have been configured for the context, check the URI. Select the service group with the matching URI, if any; otherwise, proceed down to another thread pool to find the matching URI.
-
If the base thread pool has been configured in the context, use it.
-
If the virtual host that matches the request contains the thread pool, use it.
-
If no thread pools are available from 1 to 4, use the Web Connection level thread pool.
-