XComp commented on code in PR #24132:
URL: https://github.com/apache/flink/pull/24132#discussion_r1467590709


##########
flink-kubernetes/src/main/java/org/apache/flink/kubernetes/kubeclient/resources/KubernetesLeaderElector.java:
##########
@@ -86,12 +117,38 @@ public KubernetesLeaderElector(
                                                         newLeader,
                                                         
leaderConfig.getConfigMapName())))
                         .build();
+        this.executorService = executorService;
+
+        LOG.info(
+                "Create KubernetesLeaderElector on lock {}.",
+                leaderElectionConfig.getLock().describe());
+    }
+
+    @GuardedBy("lock")
+    private void resetInternalLeaderElector() {
+        stopLeaderElectionCycle();
+
         internalLeaderElector =
                 new LeaderElector(kubernetesClient, leaderElectionConfig, 
executorService);
+        currentLeaderElectionSession = internalLeaderElector.start();
+
         LOG.info(
-                "Create KubernetesLeaderElector {} with lock identity {}.",
-                leaderConfig.getConfigMapName(),
-                leaderConfig.getLockIdentity());
+                "Triggered leader election on lock {}.", 
leaderElectionConfig.getLock().describe());
+    }
+
+    @GuardedBy("lock")
+    private void stopLeaderElectionCycle() {
+        if (internalLeaderElector != null) {
+            Preconditions.checkNotNull(currentLeaderElectionSession);
+
+            // the current leader election cycle needs to be cancelled before 
releasing the lock to
+            // avoid retrying
+            currentLeaderElectionSession.cancel(true);
+            currentLeaderElectionSession = null;
+
+            internalLeaderElector.release();

Review Comment:
   You're right. The release call would trigger the `notLeader` call when 
enabling `ReleaseOnCancel`. That was the wrong conclusion on my side. 
   
   But considering that there's this bug in 
https://github.com/fabric8io/kubernetes-client/issues/5463; should we consider 
upgrading the client for Flink 1.18? I tend to lean towards not upgrading the 
kubernetes-client. The diff between v6.6.2 and v6.8.0 appears to be quite big. 
:thinking: 



-- 
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: issues-unsubscr...@flink.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

Reply via email to