[
https://issues.apache.org/jira/browse/ZOOKEEPER-1997?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14077861#comment-14077861
]
Hongchao Deng commented on ZOOKEEPER-1997:
------------------------------------------
[~fpj]
I thought over the problem and propose the following:
1. when there is a single in zoo.cfg. It should still be standalone. (backward
compatibility)
2. when there is a dynamicConfigFile in zoo.cfg, and the dynamic file is not
empty, it shouldn't be standalone. Well, you can add more servers to the first
one.
3. I am not sure how to handle when both server lists exist in zoo.cfg and
zoo.cfg.dynamic. So I am assuming it won't. Well, I will try to take a look and
might include this check in ZOOKEEPER-1992.
> server with a single line server list shouldn't be StandaloneEnabled
> --------------------------------------------------------------------
>
> Key: ZOOKEEPER-1997
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1997
> Project: ZooKeeper
> Issue Type: Bug
> Reporter: Hongchao Deng
>
> A server goes to standalone mode if there is only a single server line in
> server list description.
> In fact, the server line was ignored.
> The test
> [testStandaloneQuorum|https://github.com/apache/zookeeper/blob/fa6d21fa8a8acba812237538e4f7172faf969d37/src/java/test/org/apache/zookeeper/test/StandaloneTest.java#L64]
> was incorrectly successful before -- the client port was ignored and the
> server was responding through the jetty port.
> When I do a client port check, it failed.
> This is caused by the logic in
> [checkvalidity|https://github.com/apache/zookeeper/blob/4bb76bd22916de8dcfe0c40f649d02d61737e871/src/java/main/org/apache/zookeeper/server/quorum/QuorumPeerConfig.java#L439]:
> {code}
> if (numMembers > 1 || (!standaloneEnabled && numMembers > 0)) {
> ...
> {code}
> This would assume it's standaloneEnabled mode and won't take anything in
> server list where the client port is defined as introduced in 3.5 dynamic
> config format.
> This is undesired after introducing reconfig because a cluster could set up
> one server and then add more later.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
