Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[TRACKING ISSUE] Do not try to connect to the old member list after the cluster changes [API-2038] #1200

Open
hz-devops-test opened this issue Jun 8, 2023 · 0 comments

Comments

@hz-devops-test
Copy link

The tracking issue for the Java side PR.

See hazelcast/hazelcast#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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant