Gestions des threads dans WildFly

Les sous-systèmes de WildFly utilisent pas mal de pools de threads, avec des possibilités de configuration et de monitoring assez hétérogènes.

On peut globalement scinder ces sous-systèmes en deux groupes. D’une part il y a ceux qui ont des threads liés au réseau qui utilisent les workers du sous-système io. D’autre part, il y a ceux qui gèrent leurs threads en interne.

Sous-système IO

Le sous-système IO est responsable de la configuration des workers de la librairie XNIO. Ces workers sont utilisés pour les entrées/sorties Web via le sous-système undertow et pour d’autres entrées/sorties réseau avec le sous-système remoting.

Configuration des workers

Dans ce sous-système, un worker est une instance de XnioWorker qui implémente ExecutorService. Un worker est donc un pool de threads.

Le sous-système a un worker par défaut.

/subsystem=io:read-resource(recursive=true)

Le default worker n’a aucune configuration explicite. Il a donc uniquement des caractéristiques par défaut.

{
  "outcome" => "success",
  "result" => {
    "default-worker" => "default",
    "buffer-pool" => undefined,
    "worker" => {"default" => {
      "io-threads" => undefined,
      "stack-size" => undefined,
      "task-core-threads" => undefined,
      "task-keepalive" => undefined,
      "task-max-threads" => undefined,
      "outbound-bind-address" => undefined,
      "server" => undefined
    }}
  }
}

  • io-threads

    • par défaut: cpuCount x 2

  • max-pool-size

  • stack-size

    • mémoire stack des threads

    • par défaut: 0 (???)

  • task-core-threads

  • task-keepalive

  • task-max-threads

cd /subsystem=io
./worker=custom-worker/:add(   \
      io-threads=10,           \
      stack-size=5,            \
      task-keepalive=600,      \
      task-max-threads=100)

Problème:

  • Log sur appel Web ⇒ "default task-1"

  • 1 seul thread "default task-NN", avec du XNIO dedans (cf. stack trace). Et 0 threads au départ, même avec task-core-threads>0

  • 32 threads "default IO-NN" pour 16 processeurs, de type WorkerThread (XNIO)

Remarque:

Il y a des "management task-NN" ainsi que des management IO-NN.

Web

see https://www.mastertheboss.com/web/jboss-web-server/using-a-custom-thread-pool-for-web-applications-running-on-wildfly/

EJB

subsystem ejb3 / thread-pool

configuration: https://docs.wildfly.org/32/wildscribe/subsystem/ejb3/thread-pool/index.html

ressources qui font référence au thread pool:

  • service=async

  • service=remote

  • service=timer-service

EE Concurrency Utilities

see * https://jakarta.ee/learn/docs/jakartaee-tutorial/current/supporttechs/concurrency-utilities/concurrency-utilities.html * https://jakarta.ee/learn/specification-guides/concurrency-explained/

subsystem EE (concurrent child)

dans la configuration fournie, on a 1 service par catégorie on peut en ajouter et les injecter dans le code

@Resource(name = "concurrent/CustomManagedExecutorService")
ManagedExecutorService executorService;
@Asynchronous(executor="java:module/env/concurrent/myExecutor")
public CompletableFuture<String> myMethod() {
    // Processing
    return Asynchronous.Result.complete(string);
}

managed-executor-service

tâches asynchrones

configuration

  • core-threads: The minimum number of threads to be used by the executor. If left undefined the default core-size is calculated based on the number of processors. A value of zero is not advised and in some cases invalid. See the queue-length attribute for details on how this value is used to determine the queuing strategy.

  • max-threads

  • queue-length

attributs runtime

  • active-thread-count

  • completed-task-count

  • current-queue-size

  • max-thread-count

  • task-count

  • thread-count

managed-scheduled-executor-service

tâches planifiées

mêmes attributs que managed-executor-service

managed-thread-factory

threads gérés par le conteneur, avec propagation de contexte

pas beaucoup d’attributs: context-service et jndi-name, comme les autres, et priority

Autres

batch

JCA

⇒ MDB?

JMS

subsystem=messaging-activemq

Pools de threads pour les clients ActiveMQ

  • global-client-scheduled-thread-pool-max-size

  • global-client-thread-pool-keepalive-time

  • global-client-scheduled-thread-pool-max-size

  • global-client-scheduled-thread-pool-keepalive-time

Pools de threads /server

  • thread-pool-max-size

  • scheduled-thread-pool-max-size

CDI

subsystem=weld

  • thread-pool-size

remoting

utilise le defaut worker

Virtual Thread

WildFly 32 n’annonce pas encore le support officiel de JDK 21 et ne supporte pas encore les virtual threads.