-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
AdaptiveServerSelection: Update stats for servers that have not responded #9801
AdaptiveServerSelection: Update stats for servers that have not responded #9801
Conversation
4e23486
to
5d294b5
Compare
Codecov Report
@@ Coverage Diff @@
## master #9801 +/- ##
============================================
- Coverage 70.15% 64.16% -5.99%
+ Complexity 5410 4975 -435
============================================
Files 1956 1908 -48
Lines 104975 102564 -2411
Branches 15892 15597 -295
============================================
- Hits 73641 65814 -7827
- Misses 26195 31975 +5780
+ Partials 5139 4775 -364
Flags with carried forward coverage won't be shown. Click here to find out more.
📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more |
ServerResponse response = _responseMap.get(serverRoutingInstance); | ||
response.receiveDataTable(dataTable, responseSize, deserializationTimeMs); | ||
|
||
// Record query completion stats immediately after receiving the response from the server instead of waiting |
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.
Not sure I follow this change. Was this a bug ?
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.
Not a bug. I just consolidated all recordStatsUponResponseArrival
into AsyncResponse instead of keeping it scattered all over. It makes sense to be here because if our response handling changes in the future, the author will be reminded to handle it.
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.
Got it. Thanks for clarifying.
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.
LGTM
label = bugfix
When broker routes a query to a server, but the server doesn't respond back within the timeout, the
numInFlightRequests
inServerRoutingStats
is never decremented. So, the algorithm now thinks that this server has outstanding requests and prefers this server lesser than the others.This PR fixes this bug. Added tests to confirm that
numInFlightRequests
is always zero - even if a server doesn't respond to a query.@siddharthteotia please review.