-
Notifications
You must be signed in to change notification settings - Fork 236
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
A62: pick_first
: sticky TRANSIENT_FAILURE and address order randomization
#357
Conversation
@markdroth : Not sure if this is sort of what we are looking for in this gRFC. Also I decided to include the config knob (since deleting is easier) even though we are leaning in favor of doing the shuffling higher up the LB policy tree. Please let me know what you feel. I can rewrite based on that. Thanks. |
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.
Thanks for doing this!
pick_first
LB policypick_first
: sticky TRANSIENT_FAILURE and address order randomization
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.
This looks really good! Comments are mostly cosmetic.
@ejona86, did you also want to review this?
before attempting to reconnect. | ||
|
||
When connections to all addresses fail, there are some similarities and some | ||
differences between the Java/Go implementations and the C-core implementation. |
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.
What's the behavior in node? @murgatroid99
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.
Node's current behavior is similar to Java and Go in regards to TF reporting. Node also does not currently implement IDLE_TIMEOUT
.
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.
Looks fine. I'd be comfortable not re-reviewing after editorial changes.
We should probably explicitly say that implementations should implement IDLE_TIMEOUT and enabled by default. We can recommend 30 minutes for the default. |
Added a note for this. Thanks. |
I've rewritten the sections by talking about the problem first and then proposing the solution. But I haven't changed the abstract. Let me know if this suffices, or you would like to see something more in the abstract. Thanks. |
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.
Sorry for the churn here -- I noticed a few more things to address.
Please let me know if you have any questions. Thanks!
Oops. I failed to the see the big comment because it did not appear on the "files" tab :(. |
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.
This looks great! Just a few minor comments remaining.
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.
This looks great! I'm happy to approve at this point, but let's wait the 2 weeks to give a chance for community feedback.
Thanks for doing this!
@markdroth : Looks like it has been two weeks since I sent the email for this proposal to grpc.io@. Could we merge this now? Thanks. |
No description provided.