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

Make request_allowed? thread safe #87

Merged
merged 1 commit into from
Aug 10, 2016
Merged

Conversation

casperisfine
Copy link
Contributor

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.

return true if closed?
half_open if error_timeout_expired?
!open?
closed? || half_open? || (open? && error_timeout_expired?)
Copy link
Contributor

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.

Copy link
Contributor Author

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.

Copy link
Contributor

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?

Copy link
Contributor Author

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.

@dylanahsmith
Copy link
Contributor

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.

@casperisfine
Copy link
Contributor Author

Ok, CI is green now (thx Dylan).

@dylanahsmith @csfrancis @sirupsen @eapache mind reviewing?

@dylanahsmith
Copy link
Contributor

👍

2 similar comments
@eapache
Copy link
Contributor

eapache commented Aug 10, 2016

👍

@sirupsen
Copy link
Contributor

👍

@dylanahsmith
Copy link
Contributor

This looks like it could be tested by using request_allowed? in a circuit breaker test and asserting that it doesn't change the state when the error timeout expires.

@dylanahsmith
Copy link
Contributor

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.

@casperisfine
Copy link
Contributor Author

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.

@dylanahsmith
Copy link
Contributor

I guess thread safety is hard to test in an integration way. Thanks for adding the test though

@casperisfine casperisfine merged commit 4123f72 into master Aug 10, 2016
@casperisfine casperisfine deleted the fix-request-allowed branch August 10, 2016 15:21
@casperisfine casperisfine temporarily deployed to rubygems August 10, 2016 15:23 Inactive
@casperisfine
Copy link
Contributor Author

Released as 0.5.2

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

Successfully merging this pull request may close these issues.

None yet

5 participants