Dispatcher pool that grows/shrinks

I am using a separate, dedicated dispatcher for executing tasks that may block. While trying to tune the thread pool, I notice that a relatively small number of threads works great for a relatively small number of tasks but performance suffers as the number of tasks grow. Likewise, a relatively large number of threads works great for a relatively large number of tasks but performance suffers if the tasks are few. This is expected since too few threads become a bottleneck if there are a large number of tasks that are just sitting in the queue. And if there are too many threads, the overhead of scheduling the threads, polling the task queue, etc. will begin to dominate if there is too little work.

Therefore, I need a thread pool that grows and shrinks on demand. The thread-pool-executor options contains some configuration parameters for maintaining a core pool size as well as a max pool size. What’s confusing is what parameters take precedence. If I set core-pool-size-min = core-pool-size-max, is core-pool-size-factor irrelevant? Same thing with max-pool-size-min and max-pool-size-max. If the are equal, is max-pool-size-factor essentially ignored?

The same question goes for fork-join-executor. Does parallelism-factor limit the number of threads regardless of what parallelism-max is set to?

The set of three parameters for number of threads works like this: CPU-cores * factor to get a number relative to the machine you are running on, that value is then capped by the min and max ending up a single number passed to the actual executor. With a min == max you are effectively ignoring the factor.

Ok, great, that’s what I suspected. This pool is being used for executing blocking tasks so the number of CPU cores is irrelevant.