-
Notifications
You must be signed in to change notification settings - Fork 168
[#1662] fix(test): Fix Netty related tests #1663
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
Conversation
0f721dc to
3f5d5da
Compare
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #1663 +/- ##
============================================
- Coverage 54.82% 54.75% -0.08%
- Complexity 2325 2741 +416
============================================
Files 366 403 +37
Lines 16218 21260 +5042
Branches 1482 2019 +537
============================================
+ Hits 8892 11641 +2749
- Misses 6804 8880 +2076
- Partials 522 739 +217 ☔ View full report in Codecov by Sentry. |
Test Results 2 377 files + 77 2 377 suites +77 4h 35m 34s ⏱️ + 34m 16s For more details on these errors, see this check. Results for commit 681a3a2. ± Comparison against base commit 45ad0b8. This pull request removes 1 and adds 2 tests. Note that renamed tests count towards both.♻️ This comment has been updated with latest results. |
|
Looks like this PR contains changes that are not related to fixing flaky tests. |
|
|
||
| public class ShuffleManagerServerFactoryTest { | ||
| @Test | ||
| public void testShuffleManagerServerType() { |
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.
Could we use @ParameterizedTest and provide the server types as test parameters?
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.
Sure.
I've removed the docs part of code. I'll put it into another PR. |
| @Test | ||
| public void testShuffleManagerServerType() { | ||
| private static Stream<Arguments> shuffleManagerServerTypeProvider() { | ||
| return Stream.of(Arguments.of(ServerType.GRPC_NETTY), Arguments.of(ServerType.GRPC)); |
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.
I liked the ServerType.values() that you had earlier, because this automatically tests all types if more are added:
| return Stream.of(Arguments.of(ServerType.GRPC_NETTY), Arguments.of(ServerType.GRPC)); | |
| return Arrays.stream(ServerType.values()); |
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.
Done.
| builder.offHeapEnable(offHeapEnabled); | ||
| builder.clientType(builder.getRssConf().get(RssClientConf.RSS_CLIENT_TYPE)); | ||
| if (builder.getClientType() == null) { | ||
| builder.clientType(builder.getRssConf().get(RssClientConf.RSS_CLIENT_TYPE)); |
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.
Why does the builder not take the client type from the rss conf? Is there a use case wher rss conf has one client type but builder.getClientType() has a different type?
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 is an issue of historical oversight in the code; it's not written in a standard way. Normally speaking, if there are fields in the builder, which are not null, we should take from the builder first. If the builder doesn't have them, then we should take from RssConf. In the current production code, even if the builder has the field(which is not null), we still basically take it from RssConf.
And that is the reason why https://github.com/apache/incubator-uniffle/pull/1663/files#diff-2c63c456bb33c64e05cbb946b316f6b26ac9153fc8ef112024e47bf8c3fc3c5aR46 does not fail when we set rss.client.type to GRPC_NETTY. Because when calling the builder's build() method, the client type will be reset to the default value GRPC through RssConf, so there has actually been a hidden bug here all along.
Of course, it's not impossible to remove those fields from the builder and set them all through RssConf, it's just harder to maintain. I think, since we already have those fields in the builder, we should support setting them through the builder, otherwise it's better to remove them altogether.
| public GrpcServer getServer(ShuffleManagerGrpcService service) { | ||
| ServerType type = conf.get(RssBaseConf.RPC_SERVER_TYPE); | ||
| if (type == ServerType.GRPC) { | ||
| if (type == ServerType.GRPC || type == ServerType.GRPC_NETTY) { |
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 does not look like fixing flaky tests but like a feature + testing it. Maybe the PR title should be rephrased.
EnricoMi
left a comment
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!
|
Could you help merge this? @EnricoMi |
What changes were proposed in this pull request?
Fix some flaky tests.
Why are the changes needed?
Fix: #1662.
Does this PR introduce any user-facing change?
No.
How was this patch tested?
Unnecessary.