[ https://issues.jboss.org/browse/JGRP-2052?page=com.atlassian.jira.plugin.... ] Bela Ban updated JGRP-2052: --------------------------- Description: The timer ({{TimeScheduler3}}) currently has the thread pool enabled by default and the pool's queue is always on. Add 2 properties: # {{timer_thread_pool.enabled}}: enables or disables the timer's thread pool and # {{timer.queue_enabled}}: enables or disables the thread pool's queue. The timer has a runner thread which continually removes tasks scheduled for execution (from a {{DelayQueue}}) and dispatches the tasks to the thread pool. If the pool is disabled (#1), then it is the runner thread which executes the task directly. This makes sense for instance, when the timer only has non-blocking tasks. An example for a blocking task is a retransmission, which might block on the send side due to insufficient credits. The timer's thread pool is by default _enabled_, but it can now be disabled to reduce the threads running. Enabling the thread pool, but disabling the timer's queue means that the pool will allocate threads up to max-threads immediately, rather than queuing the tasks. was: Currently the timer thread pool always has the queue enabled; the user can only define a max queue size. Change this to make a queue configurable, e.g. if we want a 0 or 1 min core threads size and a large max-size, and no queue enabled. This would enable users to play with small timer thread pool sizes; as a matter of fact, there would be _no timer threads_ if no tasks are running. -- This message was sent by Atlassian JIRA (v6.4.11#64026)