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

QuorumService inconsistent state #8820

gAmUssA opened this issue Aug 31, 2016 · 1 comment


None yet
3 participants
Copy link

commented Aug 31, 2016


from discussion with @metanet:

When cluster service starts during node start, it registers itself as the only member and publishes the membership event. QuorumService is a MembershipAwareService, therefore it is expected to update quorums when it receives these membership events. If I don’t miss anything, the problem is as follows: services are not registered to ServiceManager yet when cluster service publishes this event on node start. So, it seems that QuorumService is missing it and failing to update its internal quorum status (initial value is “true” but I think it should be sth like “not-decided”).

Test to reproduce.

public void test() {
        Config config = new Config();
        QuorumConfig quorumConfig = new QuorumConfig().setName(randomString()).setEnabled(true);
        HazelcastInstance hazelcastInstance = createHazelcastInstance(config);

returns true.

ZD ticket 1961

@jerrinot jerrinot added this to the 3.7.2 milestone Aug 31, 2016


This comment has been minimized.

Copy link

commented Sep 22, 2016

The simplest fix is to update the quorum state with a single (this) member when a node is starting.

The question is whether it's a desirable solution when it comes to listeners. As it could be unexpected for the users to have the listener called everytime when a member is starting.

Theoretically we could avoid calling listeners when the initial (this) member is set.
The contract of QuorumListener says Called when quorum presence state is changed.
So a possible interpretation could be: "when the quorum is established for the first time then it's not a state change". but I am not sure if this interpretation is practical.

@eminn, @metanet: WDYT?

@jerrinot jerrinot modified the milestones: 3.7.3, 3.7.2 Sep 22, 2016

@jerrinot jerrinot modified the milestones: 3.7.4, 3.7.3 Nov 1, 2016

@jerrinot jerrinot modified the milestones: 3.7.4, 3.7.5 Nov 29, 2016

@metanet metanet self-assigned this Dec 19, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.