[
https://issues.apache.org/jira/browse/ZOOKEEPER-1989?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14073986#comment-14073986
]
Alexander Shraer commented on ZOOKEEPER-1989:
---------------------------------------------
Sure.
zookeeper/server/quorum/QuorumPeerConfig.java is where the config files are
being read.
I think that you should add a new boolean field to this class, something like
"reconfigDisabled"
look for this code:
// backward compatibility - dynamic configuration in the same file as
// static configuration params see writeDynamicConfig() - we change the
// config file to new format if reconfig happens
if (dynamicConfigFileStr == null) {
configBackwardCompatibilityMode = true;
quorumVerifier = parseDynamicConfig(zkProp, electionAlg, true,
configBackwardCompatibilityMode);
checkValidity();
}
in checkValidity or after it, you should do something like this:
for (QuorumServer s: quorumVerifier.getAllMembers().values()) {
if (s.clientAddr == null) {
reconfigDisabled = true;
}
}
Next, in QuorumPeerMain you need to do something like this:
quorumPeer.setReconfigEnabled(config.isReconfigEnabled());
When the leader receives a reconfig command it executes this code:
zookeeper/server/PrepRequestProcessor.java, look for case OpCode.reconfig:
This is where you'd need to throw an exception if lzks.self.isReconfigEnabled()
== false
perhaps an APIERROR exception, not sure.
Next, you'll need to make sure that the config file is not being edited and a
dynamic file is not created.
This can also be done in setQuorumVerifier of QuorumPeer.java. Just check
self.isReconfigEnabled()
where configBackwardCompatibility is checked.
Take a look also on setLastSeenQuorumVerifier. I don't think you should change
it though, because we're not gonna have reconfigs in this mode.
Regarding the test - once ZOOKEEPER-1988 is committed you can add a test to
test/org/apache/zookeeper/server/quorum/DynamicConfigBackwardCompatibilityTest.java
Look on ReconfigRecoveryTest to see how to invoke a reconfig, and just make
sure you get an assertion back if your test starts from an old-style config
file. In order to write static config file only do what the test in
DynamicConfigBackwardCompatibilityTest does - mt[i] = new MainThread(i,
clientPorts[i], currentQuorumCfgSection, false);
the last parameter "false" means "don't write a dynamic config file"
good luck!
Alex
> backward compatibility of zoo.cfg
> ---------------------------------
>
> Key: ZOOKEEPER-1989
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1989
> Project: ZooKeeper
> Issue Type: Sub-task
> Components: tests
> Affects Versions: 3.5.0
> Reporter: Hongchao Deng
> Assignee: Hongchao Deng
> Priority: Blocker
> Fix For: 3.5.0
>
>
> Before 3.5.x, users define zoo.cfg with "clientPort" parameter which is used
> to identify on which port the server is serving clients.
> After upgrading to 3.5.x, the new format:
> {noformat}
> server.$id=$addr:$port1:$port2[:$role];[$cliAddr:]$cliPort
> {noformat}
> force users to define all the client ports on the entire ZK ensemble.
> The goal of this issue is to preserve backward compatibility upgrading 3.4 to
> 3.5.
> 1. when a user defines an old-style config file, it should function the same
> as the old way -- It should use clientPort variable and shouldn't create a
> dynamic file.
> 2. when a user with old-style config file tries to do reconfig relevant jobs,
> it should stop him and give out a warning.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
