csudharsanan commented on code in PR #3043:
URL: https://github.com/apache/helix/pull/3043#discussion_r2138336498
##########
helix-core/src/main/java/org/apache/helix/controller/stages/MessageGenerationPhase.java:
##########
@@ -250,17 +267,31 @@ private void generateMessage(final Resource resource,
final BaseControllerDataPr
pendingMessage, manager, resource, partition,
sessionIdMap, instanceName,
stateModelDef, cancellationMessage, isCancellationEnabled);
} else {
+ // Set currentReplicaNumber to provide metadata for potential
message prioritization by participant
+ int currentReplicaNumber = -1; // -1 by default
+
+ // Check if this is an upward state transition from non-second top
state to second top
+ // or top state
+ if (stateModelDef.isUpwardStateTransition(currentState, nextState)
+ && !stateModelDef.getSecondTopStates().contains(currentState)
+ && (isSecondTopState(nextState, stateModelDef)
+ || stateModelDef.getTopState().contains(nextState))) {
+
+ // Assign the replica number for prioritization
+ currentReplicaNumber = replicaNumberCounter--;
Review Comment:
I agree the variable name is confusing, but above approach would not solve
the core client problem.
Based on above suggestion, all concurrent messages would get the same
currentReplicaNumber (For e.g., as you mentioned all get 0 when starting from
scratch), making client-side prioritization impossible.
But the implementation allows each message to get a unique number (2, 1, 0),
allowing clients to prioritize availability-critical replicas over
load-balancing ones per the proposal requirements. My thought is that clients
need different numbers to implement `if (currentReplicaNumber > 1)
useHighPriorityThreadPool()`.
I think we should keep current logic but rename to maybe
"replicaPriorityNumber" to avoid confusion?
--
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
