[
https://issues.apache.org/jira/browse/ZOOKEEPER-1783?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13794306#comment-13794306
]
Alexander Shraer commented on ZOOKEEPER-1783:
---------------------------------------------
Hi Ben,
Our invariant is that the current quorum verifier has been committed / went
through consensus, and I didn't want to break it by assigning it a version that
didn't go through consensus. This restriction means that in the NEWLEADER
message we'd have to send a config with version 0 and then have
follower/observer/learner/leader make a check (when UPTODATE arrives) that
detects version = 0 and replaces it with the version from the NEWLEADER
version. It seemed that this would require more changes in more places, this is
why I chose to do it like in the patch -- basically use the fact that
lastProposedQV is an uncommitted qv we're sending to everyone, and they already
know how to handle it.
Changes to QuorumPeer:
1. Replicating the logic we have for restarting leader election to correctly
work when read-only mode is enabled.
roZkMgr.start();
+ reconfigFlagClear();
+ if (shuttingDownLE) {
+ shuttingDownLE = false;
+ startLeaderElection();
+ }
This is just duplicate of what we do for when read-only option is disabled.
Without this, restarting leader election doesn't work correctly (it keeps
spinning since shuttingDownLE = true. I noticed it because read-only test was
failing with my changes to Leader.java. After this changed work, I changed
FastLeaderElection not to restart in this case because the quorum verifier is
identical besides the version. The change above is still needed though.
The other two changes are there because I was hitting NullPointerException from
different tests that now had to invoke processReconfig (to write dynamic config
files with new version) but didn't initialize dynamic config related parameters
correctly. These changes are just performing sanity checks before using
variables that may be null.
> Distinguish initial configuration from first established configuration
> ----------------------------------------------------------------------
>
> Key: ZOOKEEPER-1783
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1783
> Project: ZooKeeper
> Issue Type: Bug
> Components: quorum, server
> Affects Versions: 3.5.0
> Reporter: Alexander Shraer
> Assignee: Alexander Shraer
> Fix For: 3.5.0
>
> Attachments: ZOOKEEPER-1783.patch, ZOOKEEPER-1783-ver1.patch,
> ZOOKEEPER-1783-ver2.patch, ZOOKEEPER-1783-ver3.patch,
> ZOOKEEPER-1783-ver4.patch, ZOOKEEPER-1783-ver5.patch,
> ZOOKEEPER-1783-ver6.patch
>
>
> We need a way to distinguish an initial config of a server and an initial
> config of a running ensemble (before any reconfigs happen). Currently both
> have version 0.
> The version of a config increases with each reconfiguration, so the problem
> is just with the initial config.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
