HBASE-29828 Upgrade TestIPC related tests to junit5

[Apache9]

No description provided.

[Apache9]

While rewriting and debugging, I found a possible problem is that, for testTimeout and testAsyncTimeout, when the test method finishes, the rpc call is still executing(sleeping), so when it finishes, it will record a tracing span in the global opentelemetry instance.

In JUnit4, since we always reset the global opentelemetry instance, so this may cause exception describe there. And in JUnit5, we do not reset the global instance but the timeout call may add new spans after we clear all the spans for the previous test and cause the next test to fail because of unexpected spans.

So the main fix is that, I added a check before shutting down the rpc server in testTimeout and testAsyncTimeout, to wait until all the pending calls are finished. In this way I think the test will be more stable.

@ndimiduk FYI.

[Apache-HBase]

🎊 +1 overall

Vote	Subsystem	Runtime	Logfile	Comment
+0 🆗	reexec	0m 29s		Docker mode activated.
			_ Prechecks _
+1 💚	dupname	0m 0s		No case conflicting files found.
+0 🆗	codespell	0m 0s		codespell was not available.
+0 🆗	detsecrets	0m 0s		detect-secrets was not available.
+1 💚	@author	0m 0s		The patch does not contain any @author tags.
+1 💚	hbaseanti	0m 0s		Patch does not have any anti-patterns.
			_ master Compile Tests _
+1 💚	mvninstall	3m 29s		master passed
+1 💚	compile	3m 30s		master passed
+1 💚	checkstyle	1m 1s		master passed
+1 💚	spotbugs	1m 40s		master passed
+1 💚	spotless	0m 52s		branch has no errors when running spotless:check.
			_ Patch Compile Tests _
+1 💚	mvninstall	3m 10s		the patch passed
+1 💚	compile	3m 26s		the patch passed
+1 💚	javac	3m 26s		the patch passed
+1 💚	blanks	0m 0s		The patch has no blanks issues.
+1 💚	checkstyle	1m 0s		the patch passed
+1 💚	spotbugs	1m 45s		the patch passed
+1 💚	hadoopcheck	12m 8s		Patch does not cause any errors with Hadoop 3.3.6 3.4.1.
+1 💚	spotless	0m 47s		patch has no errors when running spotless:check.
			_ Other Tests _
+1 💚	asflicense	0m 12s		The patch does not generate ASF License warnings.
		41m 21s

Subsystem	Report/Notes
Docker	ClientAPI=1.43 ServerAPI=1.43 base: https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-7626/1/artifact/yetus-general-check/output/Dockerfile
GITHUB PR	#7626
Optional Tests	dupname asflicense javac spotbugs checkstyle codespell detsecrets compile hadoopcheck hbaseanti spotless
uname	Linux 45230e037c07 5.4.0-1103-aws #111~18.04.1-Ubuntu SMP Tue May 23 20:04:10 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux
Build tool	maven
Personality	dev-support/hbase-personality.sh
git revision	master / 62a3b54
Default Java	Eclipse Adoptium-17.0.11+9
Max. process+thread count	84 (vs. ulimit of 30000)
modules	C: hbase-server U: hbase-server
Console output	https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-7626/1/console
versions	git=2.34.1 maven=3.9.8 spotbugs=4.7.3
Powered by	Apache Yetus 0.15.0 https://yetus.apache.org

This message was automatically generated.

[Apache-HBase]

💔 -1 overall

Vote	Subsystem	Runtime	Logfile	Comment
+0 🆗	reexec	0m 30s		Docker mode activated.
-0 ⚠️	yetus	0m 4s		Unprocessed flag(s): --brief-report-file --spotbugs-strict-precheck --author-ignore-list --blanks-eol-ignore-file --blanks-tabs-ignore-file --quick-hadoopcheck
			_ Prechecks _
			_ master Compile Tests _
+1 💚	mvninstall	3m 31s		master passed
+1 💚	compile	1m 0s		master passed
+1 💚	javadoc	0m 30s		master passed
+1 💚	shadedjars	6m 2s		branch has no errors when building our shaded downstream artifacts.
			_ Patch Compile Tests _
+1 💚	mvninstall	3m 13s		the patch passed
+1 💚	compile	1m 2s		the patch passed
+1 💚	javac	1m 2s		the patch passed
+1 💚	javadoc	0m 28s		the patch passed
+1 💚	shadedjars	5m 58s		patch has no errors when building our shaded downstream artifacts.
			_ Other Tests _
-1 ❌	unit	236m 44s	/patch-unit-hbase-server.txt	hbase-server in the patch failed.
		264m 23s

Subsystem	Report/Notes
Docker	ClientAPI=1.43 ServerAPI=1.43 base: https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-7626/1/artifact/yetus-jdk17-hadoop3-check/output/Dockerfile
GITHUB PR	#7626
Optional Tests	javac javadoc unit compile shadedjars
uname	Linux 47c68c1a5f10 5.4.0-1103-aws #111~18.04.1-Ubuntu SMP Tue May 23 20:04:10 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux
Build tool	maven
Personality	dev-support/hbase-personality.sh
git revision	master / 62a3b54
Default Java	Eclipse Adoptium-17.0.11+9
Test Results	https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-7626/1/testReport/
Max. process+thread count	3720 (vs. ulimit of 30000)
modules	C: hbase-server U: hbase-server
Console output	https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-7626/1/console
versions	git=2.34.1 maven=3.9.8
Powered by	Apache Yetus 0.15.0 https://yetus.apache.org

This message was automatically generated.

[ndimiduk]

This pattern from OTEL is annoying.

Just for a counter-idea, what if we add a notification mechanism to TestProtobufRpcServiceImpl#pause() , the test method registers a Future that is completed on the way out of the method.

[ndimiduk]

I hate to bring it up, but would 5 sec be more reliable in our CI?

[Apache9]

The timeout value is 1 secs, so I think 2 secs is enough?

[Apache9]

This pattern from OTEL is annoying.

Just for a counter-idea, what if we add a notification mechanism to TestProtobufRpcServiceImpl#pause() , the test method registers a Future that is completed on the way out of the method.

Our rpc implementation does not support this...
The timeout config is at client side, so when we reach the timeout, the client side will get a RpcTimeoutException immediately, and the call entry will be removed. Later when we receive the response from server side, we will just drop it since we can not find the call entry for this call...

[ndimiduk]

I was thinking just for the purpose of keeping the test reliable. It's all within the same process, so the main test thread would wait until notified by the end of the pause. Complete the future within a finally block and it should be enough.

But maybe my understanding here is superficial.

Thanks for digging here Duo.

[Apache9]

I was thinking just for the purpose of keeping the test reliable. It's all within the same process, so the main test thread would wait until notified by the end of the pause. Complete the future within a finally block and it should be enough.

But maybe my understanding here is superficial.

Thanks for digging here Duo.

Rpc calls run in a thread pool at server side, and we will use the same process to run all the test methods, so there is no simple way for us to wait in main thread. We can think the current fix in this PR is to make the main thread join on the thread pool for running rpc calls at server side...