Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Using shortcircuited in errorpercentage makes it hard to close circuit again #1031

Closed
JorritSalverda opened this issue Dec 30, 2015 · 6 comments

Comments

@JorritSalverda
Copy link

In HystrixCommandMetrics.java method getHealthCounts the errorpercentage is calculated as follows.

long totalCount = failure + success + timeout + threadPoolRejected + shortCircuited + semaphoreRejected;
long errorCount = failure + timeout + threadPoolRejected + shortCircuited + semaphoreRejected;
int errorPercentage = 0;

if (totalCount > 0) {
    errorPercentage = (int) ((double) errorCount / totalCount * 100);
}

To me it seems that using shortCircuited and both rejected values in the errorCount obscures the real error rate at the dependency itself, making it possible that as soon as the circuit breaker closes due to a successful canary call it closes again.

What's your experience with this?

@JorritSalverda
Copy link
Author

Never mind, when rebuilding Hystrix in .net I forgot the essential resetCounters when circuit is closed :)

@mattrjacobs
Copy link
Contributor

@JorritSalverda Yeah, the resetCounters is important :)

I think you raised a good point in the other train of thought. After considering it, it doesn't seem correct that SHORT_CIRCUITED outcomes should factor into a health percentage. I think in practice this shouldn't happen (due to resetCounters), but I think the definition should be clearer than only commands which actually attempted to run should count for/against a circuit's health.

WDYT?

@mattrjacobs mattrjacobs reopened this Dec 31, 2015
@JorritSalverda
Copy link
Author

I think it would depend on a fallback being executed successfully or an exception thrown instead whether it should count as an error. Executing the fallback is more of a warning if you compare it to the levels used in logging.

@mattrjacobs
Copy link
Contributor

I'm not sure I follow your statement above. I think fallback success/error shouldn't factor into circuit breaker activity. I think that circuit breaker health should depend solely on success/failure of the command. The point I was trying to make is that a previous SHORT-CIRCUIT outcomes gives no indication about the present health of the command, just about the past state. Therefore, I don't believe it makes sense to include it in health calculations.

So, when I have time, I will issue a PR that drops SHORT-CIRCUITs from health calculations.

@JorritSalverda
Copy link
Author

Yes you're right, it shouldn't be factored in regardless of fallback as it says nothing about the dependencies' health.

@mattrjacobs
Copy link
Contributor

Merged #1034, so closing this issue. Thanks for bringing this up, @JorritSalverda

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants