Giters

cep21 / circuit

An efficient and feature complete Hystrix like Go implementation of the circuit breaker pattern.

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

confusing ExecutionConfig & FallbackConfig MaxConcurrentRequests behavior in NewCircuitFromConfig

chrisguiney opened this issue · comments

commented

I suppose this is more user feeback than a bug, but I wanted to share some confusion I experienced w.r.t. the titular settings

NewCircuitFromConfig merges in defaultCommandProperties, but doesn't document such. When configuring, my intuition told me that if MaxConcurrentRequests is zero, then it wouldn't be enforced.

I was very surprised to see that it was enforced. When investigating, I had initially thought that the circuit was using >= when > would be correct -- if the value is zero, then it will decline all commands.
https://github.com/cep21/circuit/blob/master/v3/circuit.go#L245
https://github.com/cep21/circuit/blob/master/v3/circuit.go#L406

I was confused, because my tests passed -- so surely they weren't all being declined, just over some level. It took me a debugging session to walk through the config setup to find that the defaults are merged in.

So I was getting the default of 10 concurrent commands, which I suppose is documented as part of the netflix/hystrix

Again, I don't think that the library did anything wrong here -- it did what it advertised -- perhaps the documentation could have been more explicit about defaults, and where they get applied.

If you consider a v4, I suggest perhaps breaking away a bit from the hystrix conventions to allow for more idiomatic go. In this case, I'd suggest exposing a DefaultConfiguration variable that can be explicitly used, and allowing the circuit to check if MaxConcurrentRequests > 0.

Thanks for reading & your work on the project -- I'm sure it's challenging to write & maintain a robust and flexible circuit breaking library. If there are any changes you would consider as a result of this report, I could definitely see about finding some time to contribute.

commented

Hi!

This is good feedback. I have thought a lot about a v4 version. Now that go modules are supported in all major versions of Go, it should be possible to make a v4 without breaking people that are using versions of Go that don't support modules.

I agree, in a v4 breaking from hystrix defaults would be worth doing. I think I'll make a v4 ticket to track possible V4 changes.

commented

Will close as wontfix since we cannot change v3. But will open this up for discussion in v4 here: #115