Threadpool Swiftlet

Introduction

SwiftMQ's entire design is non-blocking. All tasks performed by other Swiftlets are dispatched to thread pools and are performed asynchronously.

All thread pools are managed by the Threadpool Swiftlet. A thread pool consists of a pool queue which is a fast ring buffer and threads to execute dispatched tasks.

Tuning

Minimum Threads

If a thread pool is created, the number of threads is pre-created and will never die. One should always have "some" minimum threads per pool if that pool is often frequented, such as JMS pools. An adequate minimum thread setting will prevent threads will die after the idle timeout and thus must be recreated if a new task instance is dispatched to the pool. One should not specify too many threads to keep the resource consumption low.

Maximum Threads

This setting avoids resource exhaustion and is also used to guarantee that, in some pools, only 1 thread will be executed at all. For e.g. the Log Manager of the Store Swiftlet uses his own pool and there should never be more than 1 thread running within that pool. Therefore, one should never change this setting if it is specified within the default configuration.

Queue Length Threshold and Additional Threads

These two attributes specify the pool growing policy. During each dispatch of a task to a pool, it is checked whether the pool is out of threads. This is the case if no idle thread is available. Normally, if a pool is configured with a minimum size of threads, these threads handle the load. At peaks, if more tasks are dispatched, the pool's queue grows up. By specifying a queue length threshold, one can define how large the pool's queue may grow until additional threads are started. Per default, both attributes have a value of 1, that is, if no idle thread is available during a task dispatch, 1 additional thread will be started. E.g. to handle peak loads, one can specify that 5 additional threads should be started if the queue length reaches 10. If the queue length is below 10, no additional threads are started and the tasks are waiting until a thread becomes available.

Idle Timeout

The idle timeout specifies the time in milliseconds after which a thread will die in the case that it is idle. If this value is too low, threads might die too early and you will get into the re-creation problem. If it is too high, threads might be idle too long and you may consume too much threads. So it really depends on the interval in which tasks are dispatched to the pool. The default idle timeout is 120000 milliseconds and should fit most requirements.

Priority

This setting specifies the thread priority of this pool. We have never seen that this has an effect at all concerning the processing behavior. The default is a normal priority (5).

Configuration

The configuration of the Threadpool Swiftlet is defined within the element

      <swiftlet name="sys$threadpool" .../>

of the router's configuration file.

Attributes of Element "swiftlet"

Definition

Values

Element List "pools", Parent Element: "swiftlet"

Threadpool Definitions. This element list contains zero or more "pool" elements with this template definition:

Definition

Values

Element List "threads", Parent Element: "pool"

Thread Assignment Definitions. This element list contains zero or more "thread" elements with this template definition:

Definition

Element List "usage", Parent Element: "swiftlet"

Active Threadpools. This element list contains zero or more "usage" elements with this template definition:

Definition

Values