UnsafePools
- Since
14 Jun 2019
Value members
Concrete methods
!!! WARNING !!! Prefer Pools.cached, unless you know what you are doing. The behavior the the Execution context itself is the same for both, but the former is actually safer to use :) ----- Cached pools should be used for blocking i/o. Without very stringent back-pressure and 100% certainty that you never overload with blocking i/o you will almost certainly freeze your application into oblivion by doing blocking i/o on a fixed thread pool.
!!! WARNING !!! Prefer Pools.cached, unless you know what you are doing. The behavior the the Execution context itself is the same for both, but the former is actually safer to use :) ----- Cached pools should be used for blocking i/o. Without very stringent back-pressure and 100% certainty that you never overload with blocking i/o you will almost certainly freeze your application into oblivion by doing blocking i/o on a fixed thread pool.
- Value Params
- daemons
whether or not the threads in the pool should be daemons or not. see java.lang.Thread#setDaemon(boolean) for the meaning for daemon threads.
- threadNamePrefix
prefixes this name to the ThreadID. This is the name that usually shows up in the logs. It also prefixes "cached" to the names.
The difference between this one and ExecutionContextMainFT is that this one allows to us to have a fixed thread pool with 1 thread.
!!! WARNING !!! Prefer Pools.fixed, unless you know what you are doing. The behavior the the Execution context itself is the same for both, but the former is actually safer to use :)
The difference between this one and ExecutionContextMainFT is that this one allows to us to have a fixed thread pool with 1 thread.
N.B.: places where it is advisable to have a fixed thread pool:
-
the pool that handles incoming HTTP requests (thus providing some back-pressure by slowing down client requests)
-
the pool that handles the connections to your DB, thus back-pressuring your DB server.
As a side-note, you probably want your HTTP pool to be smaller than your DB pool (since you might be doing multiple DB calls per request).
- Value Params
- daemons
whether or not the threads in the pool should be daemons or not. see java.lang.Thread#setDaemon(boolean) for the meaning for daemon threads.
- maxThreads
The maximum number of threads in the pool. Always defaults to 1 thread, if you accidentally give it a value < 1.
- threadNamePrefix
prefixes this name to the ThreadID. This is the name that usually shows up in the logs. It also prefixes the maxThread count.
- Returns
A fixed thread pool
!!! WARNING !!! Prefer Pools.singleThreaded, unless you know what you are doing. The behavior the the Execution context itself is the same for both, but the former is actually safer to use :) ----- A simple thread pool with one single thread. Be careful how you use it.
!!! WARNING !!! Prefer Pools.singleThreaded, unless you know what you are doing. The behavior the the Execution context itself is the same for both, but the former is actually safer to use :) ----- A simple thread pool with one single thread. Be careful how you use it.