During failover, when the client is about to try to connect to the next cluster, it resets some services including the cluster service.
In its reset logic, cluster service clears the member list version, but leaves the members as it is, as there are some services/proxies that rely on the fact that the member list cannot be empty.
This creates a problem for the failover case. After the cluster change, the client still tries to connect to the last known member list, which is the members of the previous cluster.
To solve the problem, I have introduced a new method to the cluster service, which returns the "effective" member list. That is, it returns an empty list after the service is reset, but returns the member list as expected otherwise. With that, the connection logic simply skips the old member list after the client decides to change the cluster to try to connect to.
The tracking issue for the Java side PR.
See https://github.com/hazelcast/hazelcast/pull/24745 for details.
During failover, when the client is about to try to connect to the next cluster, it resets some services including the cluster service.
In its reset logic, cluster service clears the member list version, but leaves the members as it is, as there are some services/proxies that rely on the fact that the member list cannot be empty.
This creates a problem for the failover case. After the cluster change, the client still tries to connect to the last known member list, which is the members of the previous cluster.
To solve the problem, I have introduced a new method to the cluster service, which returns the "effective" member list. That is, it returns an empty list after the service is reset, but returns the member list as expected otherwise. With that, the connection logic simply skips the old member list after the client decides to change the cluster to try to connect to.