- 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:
timer_type="new3"
timer.min_threads="2"
timer.max_threads="4"
timer.keep_alive_time="3000"
timer.queue_max_size="500"
thread_pool.enabled="true"
thread_pool.min_threads="2"
thread_pool.max_threads="8"
thread_pool.keep_alive_time="5000"
thread_pool.queue_enabled="true"
thread_pool.queue_max_size="10000"
thread_pool.rejection_policy="discard"
internal_thread_pool.enabled="true"
internal_thread_pool.min_threads="1"
internal_thread_pool.max_threads="4"
internal_thread_pool.keep_alive_time="5000"
internal_thread_pool.queue_enabled="false"
internal_thread_pool.rejection_policy="discard"
oob_thread_pool.enabled="true"
oob_thread_pool.min_threads="1"
oob_thread_pool.max_threads="8"
oob_thread_pool.keep_alive_time="5000"
oob_thread_pool.queue_enabled="false"
oob_thread_pool.queue_max_size="100"
oob_thread_pool.rejection_policy="discard"
and here's the 4.0 configuration:
thread_pool.enabled="true"
thread_pool.min_threads="2"
thread_pool.max_threads="8"
thread_pool.keep_alive_time="5000"
Nice, isn't it?
Cheers,
Bela, that's sounds great, specially in configuration manner, but, do you think that it will change for better or worse the performance / latency?
ReplyDeleteIt will certainly not make things worse. I expect latency will get a bit better as the reduced number of threads will reduce context switching as well.
ReplyDeleteMy preliminary performance tests have so far shown performance to be on par or slightly better than before. Once I've implemented JGRP-2100 [1] which reduces the number of threads required in the pool even further, and once I've revisited JGRP-2099 [2] which replaces ThreadPoolExecutor with a ForkJoinPool, I'll run some extensive tests. Stay tuned...
[1] https://issues.jboss.org/browse/JGRP-2100
[2] https://issues.jboss.org/browse/JGRP-2099
Thanks Bela, Do you know why Jgroup (4.0.5) is not clearing database table when clear_table_on_view_change is set to true
ReplyDeleteAlso Is there a way to use old style of configuration parameter with latest version. We would like to know if we can avoid xml configuration and instead use a properties file.