WildFly uses Undertow as Web server. In order to configure the amount of threads used by Web applications, we can define a Worker Thread from the io subsystem and use the Worker Thread for its HTTP listeners or just for single applications. In this tutorial we will learn how to do it.

Out of the box, the io subsystem provides a default worker that is used by Undertow:

/subsystem=io:read-resource
{
    "outcome" => "success",
    "result" => {
        "buffer-pool" => {"default" => undefined},
        "worker" => {
            "default" => undefined
        }
    }
}

We change the attributes for the default worker os simply define a new worker for our purposes as in this example:

/subsystem=io/worker=largeworker/:add(io-threads=10,stack-size=0,task-keepalive=60,task-max-threads=100)

We have defined a worker named "largerworker" with the "io-threads" set to 10, and the "task-max-threads" set to 100

Now in order to use this worker on the default http listener available in Undertow, we can simply attach it as follows:

/subsystem=undertow/server=default-server/http-listener=default/:write-attribute(name=worker,value=largeworker)

The above command needs a reload in your server configuration to take effect.

On the other hand, we can also use a specific worker at application level. This can be done through the jboss-web.xml configuration file which includes an executor-name element:

<jboss-web>
  <executor-name>largeworker</executor-name>
</jboss-web>

Once you have included this configuration in your application, the Web server will use the custom worker Threads which are named using the following criteria: [worker name]-[worker id]. The Thread pool can then be monitored using any tool like the JConsole utility (included as part of the JDK standard edition) that allows printing a dump of the Threads stack traces running in a JVM. Here is a dump of our worker pool:

Using a custom Thread pool for Web applications running on WildFly

0
0
0
s2sdefault