Relates to #154 #155.
Currently, the server maintains a threadpool for tasks classified as USER or BACKGROUND. This thread pool is implied in the docs to have a maximum size configurable by omero.threads.max_threads and a minimum pool size configurable by omero.threads.min_threads. Also, a thread timeout is supposed to be configurable with omero.threads.idle_timeout. However, beacuse the Java class ThreadPoolExecutor is used here with an ubounded LinkedBlockingQueue, this is largely not how these configs work. To paraphrase the java documentation, with a ThreadPoolExecutor you have 3 options for managing threads:
- A finite thread pool limited only by the core thread pool size and an infinite queue (this is what we currently have)
- An infinite thread pool and effectively no queue at all (this is how the
SYSTEM level thread pool works)
- A finite thread pool and finite queue. In this case as new tasks come in threads are created until the core thread pool size has been reached. Then new tasks are queued until the queue is full. Finally if the queue is full new tasks will cause new threads to be created up to the maximum pool size. After that additional tasks are rejected.
We probably want to stick with option 1, but if so we should change the configuration properties and ThreadPool constructor signature to more accurately represent what's happening. We should have a new constructor which only takes 1 pool size argument. Instead of the max_threads and min_threads configs and constructor args, there should be a single value called core_threads. This is used to set the core thread pool size in the ThreadPool. By default, core threads do not time out, but this can be changed (see this). We can decide whether we want to allow the configuration of timeouts or not, in which case we may need to also change the omero.threads.idle_timeout property and constructor argument.
In summary:
- There should be a new configuration property
omero.threads.core_threads which sets the core thread pool size for the USER and BACKGROUND thread pool.
- We should create a
ThreadPool constructor which takes only this one value instead of a min and max value.
- We should make a decision about whether to always enable timeout, always disable it, or make it configurable.
- We should deprecate
omero.threads.max_threads and omero.threads.min_threads and the ThreadPool constructor that uses them.
- We should eventually remove the old constructor and either call the new one with
core_threads if it's set and min_threads if it's not.
- We should eventually remove
omero.threads.max_threads and omero.threads.min_threads completely and perhaps throw an exception on server startup if they are set explaining that core_threads needs to be set instead.
Relates to #154 #155.
Currently, the server maintains a threadpool for tasks classified as
USERorBACKGROUND. This thread pool is implied in the docs to have a maximum size configurable byomero.threads.max_threadsand a minimum pool size configurable byomero.threads.min_threads. Also, a thread timeout is supposed to be configurable withomero.threads.idle_timeout. However, beacuse the Java class ThreadPoolExecutor is used here with an ubounded LinkedBlockingQueue, this is largely not how these configs work. To paraphrase the java documentation, with a ThreadPoolExecutor you have 3 options for managing threads:SYSTEMlevel thread pool works)We probably want to stick with option 1, but if so we should change the configuration properties and
ThreadPoolconstructor signature to more accurately represent what's happening. We should have a new constructor which only takes 1 pool size argument. Instead of themax_threadsandmin_threadsconfigs and constructor args, there should be a single value calledcore_threads. This is used to set the core thread pool size in theThreadPool. By default, core threads do not time out, but this can be changed (see this). We can decide whether we want to allow the configuration of timeouts or not, in which case we may need to also change theomero.threads.idle_timeoutproperty and constructor argument.In summary:
omero.threads.core_threadswhich sets the core thread pool size for theUSERandBACKGROUNDthread pool.ThreadPoolconstructor which takes only this one value instead of a min and max value.omero.threads.max_threadsandomero.threads.min_threadsand theThreadPoolconstructor that uses them.core_threadsif it's set andmin_threadsif it's not.omero.threads.max_threadsandomero.threads.min_threadscompletely and perhaps throw an exception on server startup if they are set explaining thatcore_threadsneeds to be set instead.