exceptionfactory commented on PR #6779: URL: https://github.com/apache/nifi/pull/6779#issuecomment-1373154084
Good find on the expired Lease handling @markap14, thanks for the additional testing. The implementation of `StandardLeaderElectionCommandProvider.findLeader()` was always returning the last Lease Holder Identity, regardless of whether the Lease had expired. This broke the contract of `LeaderElectionManager.getLeader()` which callers expected to return a `null` when there is no leader for the role requested. I updated `findLeader()` to return `Optional<String>`, and check the expiration of the Lease so that `findLeader` returns `Optional.empty()` when the Lease has expired. The expiration is determined based on `renewTime` plus `leaseDurationSeconds`, following the definition of those fields in the [Kubernetes LeaseSpec](https://kubernetes.io/docs/reference/kubernetes-api/cluster-resources/lease-v1/#LeaseSpec). To make the implementation contract clearer, I also changed the return of `LeaderElectionManager.getLeader()` from `String` to `Optional<String>`. Although the method documentation noted that `null` indicates no leader is elected, changing the return to use `Optional` clarifies that detail without requiring too many adjustments. This seemed like a good time to make the change as part of promoting `LeaderElectionManager` to an extension component interface. Following those changes, shutting down all nodes, then starting up a single node that was not previously the Cluster Coordinator or Primary Node worked as expected. The single node was able to become the leader for those roles. It is worth noting that the Lease objects continue to live in the Kubernetes namespace even if all nodes have been shutdown for an extended period. The `renewTime` indicates the last update, and the corrected logic will now update existing values as needed. -- 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...@nifi.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
