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
chore: Shutdown and awaitTermination for showcase clients #1669
Conversation
|
grpcClient.awaitTermination(TestClientInitializer.AWAIT_TERMINATION_SECONDS, TimeUnit.SECONDS); | ||
|
||
httpjsonClient.close(); | ||
httpjsonClient.awaitTermination( |
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 method is not implemented yet #1663
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.
Do we know why the deadline PR caused flakyness? The deadline PR should only affect http/json stuff in theory.
I believe it's just the addition of a bunch of tests added for the deadline PR. These tests run in parallel and the showcase server was never built for performance or for handling being spammed with retries. I added a bit of wait for the tests and have the tests run sequentially to try and help with the CI jobs. |
private static final ExecutorService DEFAULT_EXECUTOR = | ||
InstantiatingExecutorProvider.newBuilder().build().getExecutor(); |
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.
Static DEFAULT_EXECUTOR
error'd out on the unit tests. Same executor was being used and it was shutdown after the first test.
<configuration> | ||
<forkCount>1C</forkCount> | ||
<reuseForks>true</reuseForks> | ||
</configuration> |
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.
Run the tests sequentially for now to see if it helps with the CI jobs.
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.
Can we revert this change with the fix?
I'll try to break this PR into two PRs (one for |
Separate PR created here: #1677 |
[gapic-generator-java-root] Kudos, SonarCloud Quality Gate passed! 0 Bugs No Coverage information |
[java_showcase_integration_tests] Kudos, SonarCloud Quality Gate passed! 0 Bugs No Coverage information |
[java_showcase_unit_tests] Kudos, SonarCloud Quality Gate passed! 0 Bugs No Coverage information |
1 and 3 sounds good to me, with both 1 and 3 in, I think we may not need 2 anymore. |
I kept 2 in to help the server with any flakes (especially for the deadline tests that spam the server). The overall runtime increases from 45 seconds to ~2 minutes which I don't think is too bad. @blakeli0 Would you be fine with keeping this in for a few weeks to try and observe some CI stability. If this helps mitigate the issues, I can change it to be parallel again? |
SGTM, with more showcase tests being added, we should revisit this soon though. CC: @burkedavison in case there is any concerns. |
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 if we can get a green light from Burke on changing the test to sequential.
SGTM. Could we create a "reminder" issue to revisit the parallel / sequential decision in a few weeks? |
Yep. I will revisit this July 6th. |
Seeing error messages regarding orphaned channels and not cleaning up the queues for gRPC.
Error:
Few changes in this PR:
Fixes: #1680