HBASE-27756 Make request guardrail configs in RSRpcServices live updatable

[bbeaudreault]

No description provided.

[Apache-HBase]

🎊 +1 overall

Vote	Subsystem	Runtime	Comment
+0 🆗	reexec	0m 23s	Docker mode activated.
		_ Prechecks _
+1 💚	dupname	0m 0s	No case conflicting files found.
+1 💚	hbaseanti	0m 0s	Patch does not have any anti-patterns.
+1 💚	@author	0m 0s	The patch does not contain any @author tags.
		_ master Compile Tests _
+1 💚	mvninstall	3m 53s	master passed
+1 💚	compile	2m 32s	master passed
+1 💚	checkstyle	0m 36s	master passed
+1 💚	spotless	0m 45s	branch has no errors when running spotless:check.
+1 💚	spotbugs	1m 31s	master passed
		_ Patch Compile Tests _
+1 💚	mvninstall	3m 31s	the patch passed
+1 💚	compile	2m 29s	the patch passed
+1 💚	javac	2m 29s	the patch passed
+1 💚	checkstyle	0m 32s	the patch passed
+1 💚	whitespace	0m 0s	The patch has no whitespace issues.
+1 💚	hadoopcheck	13m 52s	Patch does not cause any errors with Hadoop 3.2.4 3.3.4.
+1 💚	spotless	0m 42s	patch has no errors when running spotless:check.
+1 💚	spotbugs	1m 38s	the patch passed
		_ Other Tests _
+1 💚	asflicense	0m 9s	The patch does not generate ASF License warnings.
		40m 40s

Subsystem	Report/Notes
Docker	ClientAPI=1.42 ServerAPI=1.42 base: https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-5141/1/artifact/yetus-general-check/output/Dockerfile
GITHUB PR	#5141
Optional Tests	dupname asflicense javac spotbugs hadoopcheck hbaseanti spotless checkstyle compile
uname	Linux 5696006bcb6d 5.4.0-1097-aws #105~18.04.1-Ubuntu SMP Mon Feb 13 17:50:57 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux
Build tool	maven
Personality	dev-support/hbase-personality.sh
git revision	master / 735fb43
Default Java	Eclipse Adoptium-11.0.17+8
Max. process+thread count	86 (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-5141/1/console
versions	git=2.34.1 maven=3.8.6 spotbugs=4.7.3
Powered by	Apache Yetus 0.12.0 https://yetus.apache.org

This message was automatically generated.

[Apache-HBase]

🎊 +1 overall

Vote	Subsystem	Runtime	Comment
+0 🆗	reexec	0m 51s	Docker mode activated.
-0 ⚠️	yetus	0m 2s	Unprocessed flag(s): --brief-report-file --spotbugs-strict-precheck --whitespace-eol-ignore-list --whitespace-tabs-ignore-list --quick-hadoopcheck
		_ Prechecks _
		_ master Compile Tests _
+1 💚	mvninstall	3m 38s	master passed
+1 💚	compile	0m 47s	master passed
+1 💚	shadedjars	4m 28s	branch has no errors when building our shaded downstream artifacts.
+1 💚	javadoc	0m 27s	master passed
		_ Patch Compile Tests _
+1 💚	mvninstall	3m 19s	the patch passed
+1 💚	compile	0m 47s	the patch passed
+1 💚	javac	0m 47s	the patch passed
+1 💚	shadedjars	4m 23s	patch has no errors when building our shaded downstream artifacts.
+1 💚	javadoc	0m 23s	the patch passed
		_ Other Tests _
+1 💚	unit	213m 12s	hbase-server in the patch passed.
		236m 45s

Subsystem	Report/Notes
Docker	ClientAPI=1.42 ServerAPI=1.42 base: https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-5141/1/artifact/yetus-jdk11-hadoop3-check/output/Dockerfile
GITHUB PR	#5141
Optional Tests	javac javadoc unit shadedjars compile
uname	Linux a6129f7aef58 5.4.0-137-generic #154-Ubuntu SMP Thu Jan 5 17:03:22 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux
Build tool	maven
Personality	dev-support/hbase-personality.sh
git revision	master / 735fb43
Default Java	Eclipse Adoptium-11.0.17+8
Test Results	https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-5141/1/testReport/
Max. process+thread count	2821 (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-5141/1/console
versions	git=2.34.1 maven=3.8.6
Powered by	Apache Yetus 0.12.0 https://yetus.apache.org

This message was automatically generated.

[Apache-HBase]

🎊 +1 overall

Vote	Subsystem	Runtime	Comment
+0 🆗	reexec	1m 4s	Docker mode activated.
-0 ⚠️	yetus	0m 3s	Unprocessed flag(s): --brief-report-file --spotbugs-strict-precheck --whitespace-eol-ignore-list --whitespace-tabs-ignore-list --quick-hadoopcheck
		_ Prechecks _
		_ master Compile Tests _
+1 💚	mvninstall	3m 17s	master passed
+1 💚	compile	0m 44s	master passed
+1 💚	shadedjars	4m 41s	branch has no errors when building our shaded downstream artifacts.
+1 💚	javadoc	0m 25s	master passed
		_ Patch Compile Tests _
+1 💚	mvninstall	2m 57s	the patch passed
+1 💚	compile	0m 40s	the patch passed
+1 💚	javac	0m 40s	the patch passed
+1 💚	shadedjars	4m 24s	patch has no errors when building our shaded downstream artifacts.
+1 💚	javadoc	0m 24s	the patch passed
		_ Other Tests _
+1 💚	unit	220m 48s	hbase-server in the patch passed.
		243m 55s

Subsystem	Report/Notes
Docker	ClientAPI=1.42 ServerAPI=1.42 base: https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-5141/1/artifact/yetus-jdk8-hadoop3-check/output/Dockerfile
GITHUB PR	#5141
Optional Tests	javac javadoc unit shadedjars compile
uname	Linux d7a9d520e7cd 5.4.0-144-generic #161-Ubuntu SMP Fri Feb 3 14:49:04 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux
Build tool	maven
Personality	dev-support/hbase-personality.sh
git revision	master / 735fb43
Default Java	Temurin-1.8.0_352-b08
Test Results	https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-5141/1/testReport/
Max. process+thread count	2970 (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-5141/1/console
versions	git=2.34.1 maven=3.8.6
Powered by	Apache Yetus 0.12.0 https://yetus.apache.org

This message was automatically generated.

[ndimiduk]

Will volatility of these fields introduce significant contention between handler threads? Should we also have each handler thread cache a thread-local copy of the value and refresh it periodically?

[bbeaudreault]

Thanks for looking Nick! Good question.

I'm far from an expert on the topic of cpu cache lines and such, but I've been curious about volatile for a while and googled it a few times in the past (again just now :)). There are numerous articles and SO answers out there, and it seems like the consensus is that on modern architectures the volatile read is uncontended and should be approximately the same performance of a normal read (so on the order of ns). It doesn't introduce any additional cpu opcodes and makes use of hardware memory barriers, which are close to free on x86+. It becomes a bit trickier when the value is being updated often, because then you introduce L1 cache invalidations, etc. But that's not relevant here since onConfigurationChange should be rare. I realize this is vague, but also I've never seen any indication in profiling of overhead of any of our existing volatiles (there are a bunch).

To that point, this PR follows the common pattern for how we've been dealing with onConfigurationChange. There already a bunch of other volatiles in RpcServer, RpcExecutor, etc all related to this. You bring up a good point that it might be nice to unify all of these with per-handler caching but it might require some tricky refactoring given the classes involved. I think if we wanted to do that it might make sense to do it in a separate jira and only if we can find evidence that it'd provide a performance speedup, since it'd definitely increase complexity. Not sure it's worth it here for just these 3 volatiles, when there are a bunch more in other handler/rpc related classes.

What do you think?

[ndimiduk]

You've convinced me. I would prefer simpler code if the volatile keyword is working well.