This chapter describes how Apache ActiveMQ Artemis uses and pools threads and how you can manage them.

First we’ll discuss how threads are managed and used on the server side then we’ll look at the client side.

1. Server-Side Thread Management

Thread pools exist for each of the following:

  • scheduled tasks

  • general use

  • asynchronous IO

  • paging

  • remoting (managed by Netty on a per-acceptor basis)

Broker Identification in Thread Names

Many thread names contain broker identification. This is done to assist in cases where multiple brokers are running in the same JVM (e.g. in the test-suite). The identification which appears in the thread name is determined by the following in order of precedence:

  • identity set in the internal ConfigurationImpl object (done by tests)

  • name set in broker.xml

  • the hexadecimal representation of the ActiveMQServerImpl Java Object’s identity acquired via System.identityHashCode

1.1. Scheduled Thread Pool

The scheduled thread pool is used for most activities on the server side that require running periodically or with delays. This includes tasks like scanning:

  • queues for expired messages or scheduled deliveries

  • configuration files for changes

  • unused addresses & queues for deletion

The maximum number of thread used by this pool is configure in broker.xml with the scheduled-thread-pool-max-size parameter, e.g.:

<scheduled-thread-pool-max-size>10</scheduled-thread-pool-max-size>

The default scheduled-thread-pool-max-size is 5 . A value of 0 is not allowed.

The name for threads from this pool will contain activemq-scheduled.

1.2. General Purpose Thread Pool

This general purpose thread pool is used for most asynchronous actions on the server side. The maximum number of threads used by this pool is configure in broker.xml with the thread-pool-max-size parameter, e.g.:

<thread-pool-max-size>60</thread-pool-max-size>

The default thread-pool-max-size is 30. A value of -1 signifies that the thread pool has no upper bound and new threads will be created on demand if there are not enough threads already available to satisfy demand. A value of 0 is not allowed.

Any threads in this pool which are idle for 60 seconds will be terminated.

The name for threads from this pool will contain activemq-<brokerName>.

1.3. Asynchronous IO

Threads from this pool are used for journal-related disk I/O, JDBC, & replication.

The name for threads from this pool will contain activemq-io-<brokerName>.

1.4. Paging

Threads from this pool are used to write to and read from paging (disk or JDBC).

The name for threads from this pool will contain activemq-paging-<brokerName>.

1.5. Netty Acceptors

Apache ActiveMQ Artemis will, by default, cap Netty threads on a per-acceptor basis at three times the number of cores (or hyper-threads) as reported by Runtime.getRuntime().availableProcessors() for processing network traffic. To override this value, you can set the number of threads by specifying the parameter remotingThreads in the transport configuration. See the configuring transports for more information on this.

Threads names will include the name of their corresponding acceptor with the prefix activemq-remoting-. For example, for the acceptor named amqp the corresponding thread names will contain activemq-remoting-amqp-<brokerName>.

1.6. Other Server-Side Threads

A thread dump from the server’s JVM will have other threads as well. Here’s other names you might find in a thread dump and the function they perform.

activemq-web

thread pool managed by Jetty (i.e. the embedded web server) to handle HTTP connections (e.g. from the web console or other Jolokia clients)

activemq-failure-check-thread

checks TTL on incoming connections

activemq-buffer-timeout

flushes disk IO buffers upon timeout

activemq-libaio-poller

polls AIO for callbacks

activemq-critical-analyzer

monitors for timeouts of various critical server operations

activemq-shutdown-timer

monitors configuration directory for status file to stop the server

activemq-remoting-service

in-vm connectivity and invoking failure listeners for Netty

Log4j2-TF-*-Scheduled-*

executes Log4j2 tasks related to CronTriggeringPolicy used by default log4j2.properties

2. Client-Side Thread Management

On the client side, Apache ActiveMQ Artemis maintains a single, "global" static scheduled thread pool and a single, "global" static general thread pool for use by all clients using the same classloader in that JVM instance.

The static scheduled thread pool has a maximum size of 5 threads by default. This can be changed using the scheduledThreadPoolMaxSize URI parameter.

The general purpose thread pool has an unbounded maximum size. This is changed using the threadPoolMaxSize URL parameter.

If required Apache ActiveMQ Artemis can also be configured so that each ClientSessionFactory instance does not use these "global" static pools but instead maintains its own scheduled and general purpose pool. Any sessions created from that ClientSessionFactory will use those pools instead. This is configured using the useGlobalPools boolean URL parameter.