Home
Welcome to the ResilientCommand wiki! ResilientCommand is a Resiliency library for wrapping dependency calls. Heavily inspired by Hystrix.
The idea is simple; protect against up/down- stream problems, by encapsulating calls to these dependencies in reliability patterns. This project seeks to do just that.
Find the Getting-Started guide right here
| Feature | Description | Enabled By Default |
|---|---|---|
| Timeout | If a command runs longer than x, we cancel it. | true |
| CircuitBreaker | Rolling window of errors, if circuit is broken we resort to fallback. | true |
| Fallback | A default value to return if the command fails. | requires an override |
| Semaphore | A way of minimising max parallelism per command. | true |
| Response Caching | Cache the result based on CacheKey. |
requires an override |
| Collapsing | Collapse calls to the same command, within a window, so only one gets called. | false |
| Grouping | Commands are grouped based on CommandKey. |
true |
| Notifications | A somewhat simple event system. | N/A |
All features can be Disabled and later re-enabled at runtime.
Take a look through the wiki to familiarize yourself with the concepts.
note: In order for runtime disabling/enabling of certain features, the feature must be enabled on object creation.
The flow is fairly simple. (Example with ALL features turned on)
We start with a semaphore, to only allow a certain number of threads at a time through the command.
We then take a collapser, and encapsulate the implementation in this.
This is further encapsulated by first a timeout and then a circuitbreaker.
If all goes well, the command will execute and return a results from the dependency, subsequent calls will use the cached result.
If something goes wrong (an unhandled exception is thrown) we return the fallback value If the fallback has been disabled (in configuration) or is simply not implemented, we simply throw the exception to be handled by you.
Semantics between different dependencies vary greatly, and only some of these benefit from retry logic.
Implementing it as an executionpolicy could happen in the future, but until then;
Resilient command considers what happens inside of RunAsync to be a blackbox. ResilientCommands either succeed or fail.
If you want to do retries, you should code this yourself inside of RunAsync