Ability to control what types of protections a Command group receives

[robhruska]

Right now, a Command requires its isolation keys, and will always get passed through an isolation thread pool (or semaphore, see #19) and a circuit breaker.

The circuit breaker can be disabled via config, but the thread pool will always be there.

There are a couple problems I'd like to solve with this:

1. The ability to introduce Commands into a system in a "disabled" way. We could then capture metrics on concurrency (e.g. what's the highest typical concurrency) and latency (e.g. what's the 99th percentile elapsed time) for the command, perhaps know when it would have been rejected (bot not actually reject), and then tune our configuration (pool sizes, breaker thresholds) based on actual data. Once tuned, the pools and breakers could be enabled with values that make sense. This allows for a more risk-free transition to using Mjolnir.
2. The ability to use only one protection. Maybe it doesn't make sense to use a circuit breaker for some commands, or maybe a lightweight application only has a single Command that it uses. In these cases, it might be worthwhile to disable the breaker, but keep the thread pool active.

It'd be nice to have these things wired up so they can be adjusted at runtime. More thought needs to go into them, though, and whether or not they're actually good ideas, or if there are other ways to approach the problems.

[senj]

Is this still alive? Would be great to see this implemented

[robhruska]

@senj We don't have any current plans to implement this, it's more of a nice-to-have for us.

Next major release is probably going to be a major version / breaking change that involves .NET Core compatibility, which will probably result in removing SmartThreadPool and the "old" Command classes. Not sure yet when that's slated for, but we're in the process of moving things to .NET Core so it's a likely near-term change.