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

improve broker selector utils #14733

Merged
merged 5 commits into from
Jan 9, 2025

Conversation

gortiz
Copy link
Contributor

@gortiz gortiz commented Dec 31, 2024

This PR fixes an issue on BrokerSelectorUtils when tables on distjoint brokers are used. Specifically the new test BrokerSelectorUtilsTest.getTablesCommonBrokersListTwoTablesDifferentBrokers fails in master because {"broker1"} was returned in that case.

It also includes some cleanup in the code to reduce the complexity in terms of computation but also making it easier to read. A bunch of new test have been added as well

@gortiz gortiz requested review from vrajat and yashmayya December 31, 2024 10:53
@gortiz
Copy link
Contributor Author

gortiz commented Dec 31, 2024

cc @bziobrowski a

@codecov-commenter
Copy link

codecov-commenter commented Dec 31, 2024

Codecov Report

Attention: Patch coverage is 74.28571% with 9 lines in your changes missing coverage. Please review.

Project coverage is 63.87%. Comparing base (59551e4) to head (80365fb).
Report is 1542 commits behind head on master.

Files with missing lines Patch % Lines
...main/java/org/apache/pinot/client/BrokerCache.java 0.00% 6 Missing ⚠️
...apache/pinot/client/utils/BrokerSelectorUtils.java 88.46% 0 Missing and 3 partials ⚠️
Additional details and impacted files
@@             Coverage Diff              @@
##             master   #14733      +/-   ##
============================================
+ Coverage     61.75%   63.87%   +2.12%     
- Complexity      207     1607    +1400     
============================================
  Files          2436     2703     +267     
  Lines        133233   150794   +17561     
  Branches      20636    23295    +2659     
============================================
+ Hits          82274    96317   +14043     
- Misses        44911    47279    +2368     
- Partials       6048     7198    +1150     
Flag Coverage Δ
custom-integration1 100.00% <ø> (+99.99%) ⬆️
integration 100.00% <ø> (+99.99%) ⬆️
integration1 100.00% <ø> (+99.99%) ⬆️
integration2 0.00% <ø> (ø)
java-11 63.85% <74.28%> (+2.14%) ⬆️
java-21 63.75% <74.28%> (+2.12%) ⬆️
skip-bytebuffers-false 63.87% <74.28%> (+2.12%) ⬆️
skip-bytebuffers-true 63.71% <74.28%> (+35.98%) ⬆️
temurin 63.87% <74.28%> (+2.12%) ⬆️
unittests 63.86% <74.28%> (+2.12%) ⬆️
unittests1 56.31% <ø> (+9.42%) ⬆️
unittests2 34.16% <74.28%> (+6.43%) ⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

public void getTablesCommonBrokersListTwoTables() {
_brokerData.put("table1", List.of("broker1"));
_brokerData.put("table2", List.of("broker1"));
List<String> tableList = BrokerSelectorUtils.getTablesCommonBrokers(List.of("table1", "table2"), _brokerData);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wouldn't a single assert be more readable ?
Assert.assertEquals(tableList, Array.asList("broker1"))

}

@Test
public void getTablesCommonBrokersListTwoTables() {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why does the data type of the result (List vs Set) matter ?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It doesn't depend on the returned data type. It is just that I'm keeping the older method for background compatibility reasons.

Implementation of the older method is not correct. Apart of being unnecessary expensive by allocating too much, the main issue is that depending on some conditions it either returns null or an empty set when there are not common brokers.

I'm just keeping the old method in case someone is using it outside this repo (I know we do), but the idea is to change or remove it in future.

@gortiz gortiz merged commit 6a8bdb5 into apache:master Jan 9, 2025
21 checks passed
@gortiz gortiz deleted the better-broker-selector-utils branch January 9, 2025 10:33
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.

5 participants