- Regular thread pool: used for regular messages (default has a queue)
- OOB thread pool: used for OOB messages (no queue)
- Internal thread pool: used for JGroups internal messages only. The main raison d'etre for this pool was that internal messages such as heartbeats or credits should never get queued up behind other messages, and get processed immediately.
- Timer thread pool: all tasks in a timer need to be executed by a thread pool as they can potentially block
Hence the idea to club regular and OOB thread pools into one.
When I further thought about this, I realized that incoming messages could also be handled by a queue-less thread pool: by handling RejectedExecutionException thrown when the pool is full and simply spawning a new thread to process the internal message, so it wouldn't get dropped.
The same goes for timer tasks: a timer task (e.g. a message retransmission task) cannot get dropped, or retransmission would cease. However, by using the same mechanism as for internal messages, namely spawning a new thread when the thread pool is full, this can be solved.
Therefore, in 4.0 there's only a single thread pool handling regular, OOB and internal messages, plus timer tasks.
The new thread pool has no queue, or else it would not throw a RejectedExecutionException when a task is added, but simply queue it, which is not what we want for internal messages or timer tasks.
It also has a default rejection policy of "abort" which cannot be changed (only by substituting the thread pool with a custom pool).
This dramatically reduces configuration complexity: from 4 to 1 pools, and the new thread pool only exposes min-threads, max-threads, idle-time and enabled as configuration options.
Here's an example of a 3.x configuration:
and here's the 4.0 configuration:
Nice, isn't it?