You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
Relates to #154 #155.
Currently, the server maintains a threadpool for tasks classified as
USER
orBACKGROUND
. This thread pool is implied in the docs to have a maximum size configurable byomero.threads.max_threads
and 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:SYSTEM
level thread pool works)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 themax_threads
andmin_threads
configs 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_timeout
property and constructor argument.In summary:
omero.threads.core_threads
which sets the core thread pool size for theUSER
andBACKGROUND
thread pool.ThreadPool
constructor which takes only this one value instead of a min and max value.omero.threads.max_threads
andomero.threads.min_threads
and theThreadPool
constructor that uses them.core_threads
if it's set andmin_threads
if it's not.omero.threads.max_threads
andomero.threads.min_threads
completely and perhaps throw an exception on server startup if they are set explaining thatcore_threads
needs to be set instead.The text was updated successfully, but these errors were encountered: