apurtell commented on code in PR #2288:
URL: https://github.com/apache/phoenix/pull/2288#discussion_r2411830824
##########
phoenix-core-client/src/main/java/org/apache/phoenix/jdbc/HAGroupStoreManager.java:
##########
@@ -100,6 +137,17 @@ public boolean isMutationBlocked(String haGroupName)
throws IOException {
return false;
}
+ public boolean isHAGroupOnClientStale(String haGroupName) throws
IOException, SQLException {
+ if (checkStaleCRRForEveryMutation) {
+ HAGroupStoreClient haGroupStoreClient =
getHAGroupStoreClient(haGroupName);
+ //If local cluster is not ACTIVE/ACTIVE_TO_STANDBY, it means the
Failover CRR is stale on client
+ //As they are trying to write/read from a STANDBY cluster.
+ return haGroupStoreClient.getPolicy() ==
HighAvailabilityPolicy.FAILOVER &&
Review Comment:
This doesn't allow for future evolution where the CRR is valid but the local
cluster is simply in the wrong state for a given operation. In other words,
just because a cluster is in the wrong state for a given operation it doesn't
mean the client does not have the most up to date CRR.
In the future some operations may be allowed on the STANDBY side. At least,
this should not foreclose the possibility.
In that future case, simply assuming the latest state is "stale" because of
disallowed operation, doing a refresh, and getting the same state back, then
fetching again because the state did not change (it is actually up to date),
would cause looping?
What I am suggesting is getting away from thinking "we are stale"
(definitive, we will always assume we are not up to date) to "we have done
something unexpectedly invalid, let's double check we are using the correct
policy" (not definitive, maybe we are up to date or maybe not).
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
