PHOENIX-6500 Allow 4.16 client to connect to 5.1 server

[virajjasani]

No description provided.

[stoty]

💔 -1 overall

Vote	Subsystem	Runtime	Comment
+0 🆗	reexec	6m 27s	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.
-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.
		_ master Compile Tests _
+1 💚	mvninstall	28m 43s	master passed
+0	hbaserecompile	37m 26s	HBase recompiled.
+1 💚	compile	1m 17s	master passed
+1 💚	checkstyle	0m 50s	master passed
+1 💚	javadoc	1m 5s	master passed
+0 🆗	spotbugs	3m 39s	phoenix-core in master has 965 extant spotbugs warnings.
		_ Patch Compile Tests _
+1 💚	mvninstall	20m 18s	the patch passed
+0	hbaserecompile	32m 18s	HBase recompiled.
+1 💚	compile	1m 15s	the patch passed
+1 💚	javac	1m 15s	the patch passed
-1 ❌	checkstyle	0m 49s	phoenix-core: The patch generated 17 new + 655 unchanged - 1 fixed = 672 total (was 656)
+1 💚	whitespace	0m 0s	The patch has no whitespace issues.
+1 💚	javadoc	0m 59s	the patch passed
+1 💚	spotbugs	3m 58s	the patch passed
		_ Other Tests _
-1 ❌	unit	123m 2s	phoenix-core in the patch failed.
+1 💚	asflicense	0m 33s	The patch does not generate ASF License warnings.
		213m 5s

Subsystem	Report/Notes
Docker	ClientAPI=1.41 ServerAPI=1.41 base: https://ci-hadoop.apache.org/job/Phoenix/job/Phoenix-PreCommit-GitHub-PR/job/PR-1257/1/artifact/yetus-general-check/output/Dockerfile
GITHUB PR	#1257
Optional Tests	dupname asflicense javac javadoc unit spotbugs hbaserebuild hbaseanti checkstyle compile
uname	Linux 68620b6a1063 4.15.0-128-generic #131-Ubuntu SMP Wed Dec 9 06:57:35 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
Build tool	maven
Personality	dev/phoenix-personality.sh
git revision	master / fcdf5bc
Default Java	Private Build-1.8.0_242-8u242-b08-0ubuntu3~16.04-b08
checkstyle	https://ci-hadoop.apache.org/job/Phoenix/job/Phoenix-PreCommit-GitHub-PR/job/PR-1257/1/artifact/yetus-general-check/output/diff-checkstyle-phoenix-core.txt
unit	https://ci-hadoop.apache.org/job/Phoenix/job/Phoenix-PreCommit-GitHub-PR/job/PR-1257/1/artifact/yetus-general-check/output/patch-unit-phoenix-core.txt
Test Results	https://ci-hadoop.apache.org/job/Phoenix/job/Phoenix-PreCommit-GitHub-PR/job/PR-1257/1/testReport/
Max. process+thread count	10514 (vs. ulimit of 30000)
modules	C: phoenix-core U: phoenix-core
Console output	https://ci-hadoop.apache.org/job/Phoenix/job/Phoenix-PreCommit-GitHub-PR/job/PR-1257/1/console
versions	git=2.7.4 maven=3.3.9 spotbugs=4.1.3
Powered by	Apache Yetus 0.12.0 https://yetus.apache.org

This message was automatically generated.

[apurtell]

Per https://phoenix.apache.org/upgrading.html

An older client (two minor versions back) will work with a newer server jar when the minor version is different, but not visa versa.
In other words, clients do not need to be upgraded in lock step with the server.

Does this mean you also need

new MajorMinorVersion(4, 15)
new MajorMinorVersion(4, 14)

? This 4.16 client might run against a 4.14 server before upgrade, or a 4.15 server before upgrade? If supporting clients two minor versions back.

[virajjasani]

Basically we have these validations:

1. Client major and minor cannot be ahead of server
2. Client major version must at least be up to server major version

What we are doing here is relaxing validation no 2. If we already know of client with old major version (4.x) being compatible to server with new major version (5.x), then we can relax major compatibility restriction (rule no 2) by adding such specific major/minor versions in this map.
In future, if we release 4.17 and we are aware that 4.17 client is backward compatible with 5.1 and 5.2 servers, we can add new entires in this map:

new MajorMinorVersion(5, 1), new MajorMinorVersion(4, 17) => 4.17 client can connect to 5.1 server
new MajorMinorVersion(5, 2), new MajorMinorVersion(4, 17) => 4.17 client can connect to 5.2 server
new MajorMinorVersion(5, 2), new MajorMinorVersion(4, 16) => 4.16 client can connect to 5.2 server

Without updating above entires, 4.17 client would not be able to connect to any 5.x server because rule no 2 (mentioned above) will fail this with:

java.sql.SQLException: ERROR 2006 (INT08): Incompatible jars detected between client and server. Major version of client is less than that of the server. Client version: 4.17.0; Server version: 5.1.0

This 4.16 client might run against a 4.14 server before upgrade, or a 4.15 server before upgrade?

This might never need to be supported unless I am missing something. So let's say we are running 4.14 client and server, now we upgrade server to 4.15 and client remains at 4.14, we are good. Instead of upgrading client, we again decide to upgrade server to 4.16, and we are still good because 4.14 client can connect to 4.16 server.
Before we upgrade server to 5.1, we will want to bring client to 4.16 so that 4.16 client can connect to 5.1 server.
However, in this entire case, we never need 4.16 client to run against 4.14/4.15 server. Correct?