public interface HystrixThreadPool
HystrixCommand.run()
on separate threads when configured to do so with HystrixCommandProperties.executionIsolationStrategy()
.
Typically each HystrixCommandGroupKey
has its own thread-pool so that any one group of commands can not starve others from being able to run.
A HystrixCommand
can be configured with a thread-pool explicitly by injecting a HystrixThreadPoolKey
or via the
HystrixCommandProperties.executionIsolationThreadPoolKeyOverride()
otherwise it
will derive a HystrixThreadPoolKey
from the injected HystrixCommandGroupKey
.
The pool should be sized large enough to handle normal healthy traffic but small enough that it will constrain concurrent execution if backend calls become latent.
For more information see the Github Wiki: https://github.com/Netflix/Hystrix/wiki/Configuration#wiki-ThreadPool and https://github.com/Netflix/Hystrix/wiki/How-it-Works#wiki-Isolation
Modifier and Type | Interface and Description |
---|---|
static class |
HystrixThreadPool.Factory |
static class |
HystrixThreadPool.HystrixThreadPoolDefault |
Modifier and Type | Method and Description |
---|---|
java.util.concurrent.ExecutorService |
getExecutor()
Implementation of
ThreadPoolExecutor . |
rx.Scheduler |
getScheduler() |
rx.Scheduler |
getScheduler(rx.functions.Func0<java.lang.Boolean> shouldInterruptThread) |
boolean |
isQueueSpaceAvailable()
Whether the queue will allow adding an item to it.
|
void |
markThreadCompletion()
Mark when a thread completes executing a command.
|
void |
markThreadExecution()
Mark when a thread begins executing a command.
|
void |
markThreadRejection()
Mark when a command gets rejected from the threadpool
|
java.util.concurrent.ExecutorService getExecutor()
ThreadPoolExecutor
.rx.Scheduler getScheduler()
rx.Scheduler getScheduler(rx.functions.Func0<java.lang.Boolean> shouldInterruptThread)
void markThreadExecution()
void markThreadCompletion()
void markThreadRejection()
boolean isQueueSpaceAvailable()
This allows dynamic control of the max queueSize versus whatever the actual max queueSize is so that dynamic changes can be done via property changes rather than needing an app restart to adjust when commands should be rejected from queuing up.