Alexander Shraer commented on ZOOKEEPER-2865:

This sounds equivalent to a situation where Server 3 starts later with an 
initial config that makes it impossible for it to reach any of the servers.
We don't check that all servers have connected or synced before allowing the 
reconfig to proceed - only that a quorum is up and connected. 

So yes, restarting the server with a config allowing it to reach at least one 
other server may be required, but I don't think that this is a bug. 

> Reconfig Causes Inconsistent Configuration file among the nodes
> ---------------------------------------------------------------
>                 Key: ZOOKEEPER-2865
>                 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2865
>             Project: ZooKeeper
>          Issue Type: Bug
>          Components: leaderElection, quorum, server
>    Affects Versions: 3.5.3
>            Reporter: Jeffrey F. Lukman
>         Attachments: ZK-2865.pdf
> When we run our Distributed system Model Checking (DMCK) in ZooKeeper v3.5.3
> by following the workload in ZK-2778:
> - initially start 2 ZooKeeper nodes
> - start 3 new nodes
> - do a reconfiguration (the complete reconfiguration is attached in the 
> document)
> We think our DMCK found this following bug:
> - while one of the just joined nodes has not received the latest 
> configuration update 
> (called as node X), the initial leader node closed its port, 
> therefore causing the node X to be isolated.
> For complete information of the bug, please see the document that is attached.

This message was sent by Atlassian JIRA

Reply via email to