[
https://issues.apache.org/jira/browse/ZOOKEEPER-2193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14558599#comment-14558599
]
Alexander Shraer commented on ZOOKEEPER-2193:
---------------------------------------------
Thanks for the patch! here are some comments:
One can use reconfig -add to change the ports of a server dynamically,
basically adding a server that is already in the system, with different ports.
In that case it is possible that all the ports will be the same but one. To do
this "nextServers.remove(qs.id);" removes the old spec of a server and the
following line adds the new spec. To avoid checking a server against its old
self, I think that nextServers.remove(qs.id); should go before your checks.
Also, why do you need joinedServers, isn't nextServers defined above your code
sufficient ?
[~michim], can you take a look as well ? do you know if the same address:port
can be shared by different servers ? (please see comment above by [~Yasuhito
Fukuda])
> reconfig command completes even if parameter is wrong obviously
> ---------------------------------------------------------------
>
> Key: ZOOKEEPER-2193
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2193
> Project: ZooKeeper
> Issue Type: Bug
> Components: leaderElection, server
> Affects Versions: 3.5.0
> Environment: CentOS7 + Java7
> Reporter: Yasuhito Fukuda
> Attachments: ZOOKEEPER-2193.patch
>
>
> Even if reconfig parameter is wrong, it was confirmed to complete.
> refer to the following.
> - Ensemble consists of four nodes
> {noformat}
> [zk: vm-101:2181(CONNECTED) 0] config
> server.1=192.168.100.101:2888:3888:participant
> server.2=192.168.100.102:2888:3888:participant
> server.3=192.168.100.103:2888:3888:participant
> server.4=192.168.100.104:2888:3888:participant
> version=100000000
> {noformat}
> - add node by reconfig command
> {noformat}
> [zk: vm-101:2181(CONNECTED) 9] reconfig -add
> server.5=192.168.100.104:2888:3888:participant;0.0.0.0:2181
> Committed new configuration:
> server.1=192.168.100.101:2888:3888:participant
> server.2=192.168.100.102:2888:3888:participant
> server.3=192.168.100.103:2888:3888:participant
> server.4=192.168.100.104:2888:3888:participant
> server.5=192.168.100.104:2888:3888:participant;0.0.0.0:2181
> version=300000007
> {noformat}
> server.4 and server.5 of the IP address is a duplicate.
> In this state, reader election will not work properly.
> Besides, it is assumed an ensemble will be undesirable state.
> I think that need a parameter validation when reconfig.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
