HADOOP-19469. Set Curator Connection Timeout.

[xyu]

JIRA: HADOOP-19469. Set Curator Connection Timeout.

Curator 5.2.0 has a default "connection timeout" of 15s:

https://github.com/apache/curator/blob/apache-curator-5.2.0/curator-framework/src/main/java/org/apache/curator/framework/CuratorFrameworkFactory.java#L63

And it will throw a warning if the Zookeeper session timeout is less than the Curator connection timeout:

https://github.com/apache/curator/blob/apache-curator-5.2.0/curator-client/src/main/java/org/apache/curator/CuratorZookeeperClient.java#L117-L120

The Hadoop default for ZK timeout is set to 10s:

https://github.com/apache/hadoop/blob/0dd9bf8/hadoop-common-project/hadoop-common/src/main/java/org/apache/hadoop/fs/CommonConfigurationKeys.java#L414-L416

Which means without setting the "connection timeout" a default installation will keep warning about the connection timeout for Curator being lower than the requested session timeout. This sets both timeout values to override the Curator default.

Another option is to change the default Hadoop ZK timeout from 10s to 15s.

Description of PR

How was this patch tested?

For code changes:

• Does the title or this PR starts with the corresponding JIRA issue id (e.g. 'HADOOP-17799. Your PR title ...')?
• Object storage: have the integration tests been executed and the endpoint declared according to the connector-specific documentation?
• If adding new dependencies to the code, are these dependencies licensed in a way that is compatible for inclusion under ASF 2.0?
• If applicable, have you updated the LICENSE, LICENSE-binary, NOTICE-binary files?

[hadoop-yetus]

💔 -1 overall

Vote	Subsystem	Runtime	Logfile	Comment
+0 🆗	reexec	0m 59s		Docker mode activated.
			_ Prechecks _
+1 💚	dupname	0m 0s		No case conflicting files found.
+0 🆗	codespell	0m 1s		codespell was not available.
+0 🆗	detsecrets	0m 1s		detect-secrets was not available.
+1 💚	@author	0m 0s		The patch does not contain any @author tags.
-1 ❌	test4tests	0m 0s		The patch doesn't appear to include any new or modified tests. Please justify why no new tests are needed for this patch. Also please list what manual steps were performed to verify this patch.
			_ trunk Compile Tests _
+1 💚	mvninstall	37m 53s		trunk passed
+1 💚	compile	15m 34s		trunk passed with JDK Ubuntu-11.0.26+4-post-Ubuntu-1ubuntu120.04
+1 💚	compile	13m 38s		trunk passed with JDK Private Build-1.8.0_442-8u442-b06us1-0ubuntu120.04-b06
+1 💚	checkstyle	1m 16s		trunk passed
+1 💚	mvnsite	1m 38s		trunk passed
+1 💚	javadoc	1m 15s		trunk passed with JDK Ubuntu-11.0.26+4-post-Ubuntu-1ubuntu120.04
+1 💚	javadoc	0m 53s		trunk passed with JDK Private Build-1.8.0_442-8u442-b06us1-0ubuntu120.04-b06
+1 💚	spotbugs	2m 30s		trunk passed
+1 💚	shadedclient	36m 14s		branch has no errors when building and testing our client artifacts.
			_ Patch Compile Tests _
+1 💚	mvninstall	0m 55s		the patch passed
+1 💚	compile	14m 47s		the patch passed with JDK Ubuntu-11.0.26+4-post-Ubuntu-1ubuntu120.04
+1 💚	javac	14m 47s		the patch passed
+1 💚	compile	13m 32s		the patch passed with JDK Private Build-1.8.0_442-8u442-b06us1-0ubuntu120.04-b06
+1 💚	javac	13m 32s		the patch passed
+1 💚	blanks	0m 0s		The patch has no blanks issues.
+1 💚	checkstyle	1m 12s		the patch passed
+1 💚	mvnsite	1m 37s		the patch passed
+1 💚	javadoc	1m 10s		the patch passed with JDK Ubuntu-11.0.26+4-post-Ubuntu-1ubuntu120.04
+1 💚	javadoc	0m 53s		the patch passed with JDK Private Build-1.8.0_442-8u442-b06us1-0ubuntu120.04-b06
+1 💚	spotbugs	2m 42s		the patch passed
+1 💚	shadedclient	36m 28s		patch has no errors when building and testing our client artifacts.
			_ Other Tests _
+1 💚	unit	14m 46s		hadoop-common in the patch passed.
+1 💚	asflicense	1m 5s		The patch does not generate ASF License warnings.
		201m 51s

Subsystem	Report/Notes
Docker	ClientAPI=1.48 ServerAPI=1.48 base: https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-7426/1/artifact/out/Dockerfile
GITHUB PR	#7426
Optional Tests	dupname asflicense compile javac javadoc mvninstall mvnsite unit shadedclient spotbugs checkstyle codespell detsecrets
uname	Linux 1457f150b128 5.15.0-130-generic #140-Ubuntu SMP Wed Dec 18 17:59:53 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux
Build tool	maven
Personality	dev-support/bin/hadoop.sh
git revision	trunk / 8785f85
Default Java	Private Build-1.8.0_442-8u442-b06us1-0ubuntu120.04-b06
Multi-JDK versions	/usr/lib/jvm/java-11-openjdk-amd64:Ubuntu-11.0.26+4-post-Ubuntu-1ubuntu120.04 /usr/lib/jvm/java-8-openjdk-amd64:Private Build-1.8.0_442-8u442-b06us1-0ubuntu120.04-b06
Test Results	https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-7426/1/testReport/
Max. process+thread count	3151 (vs. ulimit of 5500)
modules	C: hadoop-common-project/hadoop-common U: hadoop-common-project/hadoop-common
Console output	https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-7426/1/console
versions	git=2.25.1 maven=3.6.3 spotbugs=4.2.2
Powered by	Apache Yetus 0.14.0 https://yetus.apache.org

This message was automatically generated.

[slfan1989]

@xyu Thanks for the contribution! LGTM. I think setting the timeout parameters this way is acceptable.

[Hexiaoqiao]

Thanks @xyu . How about add another single configure item about connection timeout here? Actually for zookeeper, the connection timeout is calculated by sessionTimeout rather than equal to sessionTimeout.

[xyu]

How about add another single configure item about connection timeout here?

Sure we can do that, what do you think about hadoop.zk.curator-connection-timeout-ms with a default value of 10000 to match the current hadoop.zk.timeout-ms default config? I was a bit hesitant to do this at first because I find it a little annoying that we have to expose a tuning for Curator into Hadoop configs but I'm not against that approach either.

Actually for zookeeper, the connection timeout is calculated by sessionTimeout rather than equal to sessionTimeout.

Yeah I guess this is true, ZK will negotiate a timeout with the client based on it's allowed max/min range on the server and what the client requests. So I guess in theory someone could say set a 60s timeout for a default ZK install and end up getting capped at 40s (20 ticks * 2000ms per tick). That setting would effectively set Curator connection timeout to 60s on top of a ZK connection timeout of 40s. (Similar to how we currently default to 15s Curator connection timeout on top of a 10s timeout ZK connection.)

I'm actually not sure what the failure scenario looks like for these Curator "connection timeout" being longer than the underlying connection. I see that Curator warns about it but I don't have an in depth understanding of what happens with Curator when configured this way.

@Hexiaoqiao what do you think is the best way to resolve this? Should we just warn users in docs that Curator connection timeout needs to be lower than ZK session timeout and that the session timeout is negotiated? Something else?

[Hexiaoqiao]

Thanks @xyu for your detailed comments.

what do you think about hadoop.zk.curator-connection-timeout-ms with a default value of 10000 to match the current hadoop.zk.timeout-ms default config.

+1.

I was a bit hesitant to do this at first because I find it a little annoying that we have to expose a tuning for Curator into Hadoop configs.

Strong +1 from my side. Now the config items is so many to confuse end user. I have no idea to improve that currently. Back to this PR, I think expose ZK/Curator config is proper based on the current status because we could not manage ZK/Curator logic in Hadoop community, so leave the choice to end user maybe one reasonable tradeoff.

About the default value, I prefer change the default Hadoop ZK timeout from 10s to 15s and give hadoop.zk.curator-connection-timeout-ms with 10000ms by default.

Thanks again.