-
Notifications
You must be signed in to change notification settings - Fork 80
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
Make request_allowed? thread safe #87
Conversation
return true if closed? | ||
half_open if error_timeout_expired? | ||
!open? | ||
closed? || half_open? || (open? && error_timeout_expired?) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
error_timeout_expired?
uses @errors.last
which is calling .last
on an array. That is probably safe to do in ruby due to the vm lock, but we might want to have a @last
instance variable in the SlidingWindow class if you want it to be accessed in a thread-safe way for jruby.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Indeed. But JRuby isn't really a concern at this point since we rely on C extensions.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Might want to leave a comment that open? && error_timeout_expired?
is intended as a non-mutating equivalent check to "should transition to half-open"?
Or should that condition even just go in half_open?
to begin with?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Or should that condition even just go in half_open? to begin with?
It can't really go in half_open?
because then you wouldn't know if you have to make a transition or not. So yeah that piece isn't necessarily trivial to understand. I'm usually not a comment guy but it's likely worth it here.
Seems like the right approach. It just looks like CI isn't setup correctly anymore, since it is getting connect errors and retrying a CI run on master produced errors now when it was passing 29 days ago. |
e53d172
to
655b3c7
Compare
Ok, CI is green now (thx Dylan). @dylanahsmith @csfrancis @sirupsen @eapache mind reviewing? |
👍 |
2 similar comments
👍 |
👍 |
This looks like it could be tested by using |
655b3c7
to
635558e
Compare
It looks like only UnprotectedResource#request_allowed? is tested in the test suite. It doesn't look like there are any tests for CircuitBreaker#request_allowed? or ProtectedResource#request_allowed? which delegates to the circuit breaker. |
635558e
to
3f96882
Compare
I added a test, but since the state query methods were all private I had to publicize them. And yes CircuitBreaker is mostly tested in an integration way. |
I guess thread safety is hard to test in an integration way. Thanks for adding the test though |
3f96882
to
c98e3c8
Compare
c98e3c8
to
f4cdec2
Compare
Released as |
First draft for #86
The idea here is to remove any side effect
request_allowed?
might have, so that it's safe to call it from a threaded environment.NB: The other circuit breaker methods stays unsafe and it's the adapter's responsibility to call them safely.