[jira] [Updated] (ZOOKEEPER-851) ZK lets any node to become an observer
[ https://issues.apache.org/jira/browse/ZOOKEEPER-851?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rakesh R updated ZOOKEEPER-851: --- Issue Type: Bug (was: Sub-task) Parent: (was: ZOOKEEPER-1045) > ZK lets any node to become an observer > -- > > Key: ZOOKEEPER-851 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-851 > Project: ZooKeeper > Issue Type: Bug > Components: quorum, server >Affects Versions: 3.3.1 >Reporter: Vishal Kher >Priority: Critical > Fix For: 3.6.0 > > Attachments: ZOOKEEPER-851.patch > > > I had a 3 node cluster running. The zoo.cfg on each contained 3 entries as > show below: > tickTime=2000 > dataDir=/var/zookeeper > clientPort=2181 > initLimit=5 > syncLimit=2 > server.0=10.150.27.61:2888:3888 > server.1=10.150.27.62:2888:3888 > server.2=10.150.27.63:2888:3888 > I wanted to add another node to the cluster. In fourth node's zoo.cfg, I > created another entry for that node and started zk server. The zoo.cfg on the > first 3 nodes was left unchanged. The fourth node was able to join the > cluster even though the 3 nodes had no idea about the fourth node. > zoo.cfg on fourth node: > tickTime=2000 > dataDir=/var/zookeeper > clientPort=2181 > initLimit=5 > syncLimit=2 > server.0=10.150.27.61:2888:3888 > server.1=10.150.27.62:2888:3888 > server.2=10.150.27.63:2888:3888 > server.3=10.17.117.71:2888:3888 > It looks like 10.17.117.71 is becoming an observer in this case. I was > expecting that the leader will reject 10.17.117.71. > # telnet 10.17.117.71 2181 > Trying 10.17.117.71... > Connected to 10.17.117.71. > Escape character is '^]'. > stat > Zookeeper version: 3.3.0--1, built on 04/02/2010 22:40 GMT > Clients: > /10.17.117.71:37297[1](queued=0,recved=1,sent=0) > Latency min/avg/max: 0/0/0 > Received: 3 > Sent: 2 > Outstanding: 0 > Zxid: 0x20065 > Mode: follower > Node count: 288 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (ZOOKEEPER-851) ZK lets any node to become an observer
[ https://issues.apache.org/jira/browse/ZOOKEEPER-851?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michi Mutsuzaki updated ZOOKEEPER-851: -- Fix Version/s: (was: 3.5.0) 3.6.0 > ZK lets any node to become an observer > -- > > Key: ZOOKEEPER-851 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-851 > Project: ZooKeeper > Issue Type: Sub-task > Components: quorum, server >Affects Versions: 3.3.1 >Reporter: Vishal Kher >Priority: Critical > Fix For: 3.6.0 > > Attachments: ZOOKEEPER-851.patch > > > I had a 3 node cluster running. The zoo.cfg on each contained 3 entries as > show below: > tickTime=2000 > dataDir=/var/zookeeper > clientPort=2181 > initLimit=5 > syncLimit=2 > server.0=10.150.27.61:2888:3888 > server.1=10.150.27.62:2888:3888 > server.2=10.150.27.63:2888:3888 > I wanted to add another node to the cluster. In fourth node's zoo.cfg, I > created another entry for that node and started zk server. The zoo.cfg on the > first 3 nodes was left unchanged. The fourth node was able to join the > cluster even though the 3 nodes had no idea about the fourth node. > zoo.cfg on fourth node: > tickTime=2000 > dataDir=/var/zookeeper > clientPort=2181 > initLimit=5 > syncLimit=2 > server.0=10.150.27.61:2888:3888 > server.1=10.150.27.62:2888:3888 > server.2=10.150.27.63:2888:3888 > server.3=10.17.117.71:2888:3888 > It looks like 10.17.117.71 is becoming an observer in this case. I was > expecting that the leader will reject 10.17.117.71. > # telnet 10.17.117.71 2181 > Trying 10.17.117.71... > Connected to 10.17.117.71. > Escape character is '^]'. > stat > Zookeeper version: 3.3.0--1, built on 04/02/2010 22:40 GMT > Clients: > /10.17.117.71:37297[1](queued=0,recved=1,sent=0) > Latency min/avg/max: 0/0/0 > Received: 3 > Sent: 2 > Outstanding: 0 > Zxid: 0x20065 > Mode: follower > Node count: 288 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (ZOOKEEPER-851) ZK lets any node to become an observer
[ https://issues.apache.org/jira/browse/ZOOKEEPER-851?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Shraer updated ZOOKEEPER-851: --- Issue Type: Sub-task (was: Bug) Parent: ZOOKEEPER-1045 > ZK lets any node to become an observer > -- > > Key: ZOOKEEPER-851 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-851 > Project: ZooKeeper > Issue Type: Sub-task > Components: quorum, server >Affects Versions: 3.3.1 >Reporter: Vishal Kher >Priority: Critical > Fix For: 3.5.0 > > Attachments: ZOOKEEPER-851.patch > > > I had a 3 node cluster running. The zoo.cfg on each contained 3 entries as > show below: > tickTime=2000 > dataDir=/var/zookeeper > clientPort=2181 > initLimit=5 > syncLimit=2 > server.0=10.150.27.61:2888:3888 > server.1=10.150.27.62:2888:3888 > server.2=10.150.27.63:2888:3888 > I wanted to add another node to the cluster. In fourth node's zoo.cfg, I > created another entry for that node and started zk server. The zoo.cfg on the > first 3 nodes was left unchanged. The fourth node was able to join the > cluster even though the 3 nodes had no idea about the fourth node. > zoo.cfg on fourth node: > tickTime=2000 > dataDir=/var/zookeeper > clientPort=2181 > initLimit=5 > syncLimit=2 > server.0=10.150.27.61:2888:3888 > server.1=10.150.27.62:2888:3888 > server.2=10.150.27.63:2888:3888 > server.3=10.17.117.71:2888:3888 > It looks like 10.17.117.71 is becoming an observer in this case. I was > expecting that the leader will reject 10.17.117.71. > # telnet 10.17.117.71 2181 > Trying 10.17.117.71... > Connected to 10.17.117.71. > Escape character is '^]'. > stat > Zookeeper version: 3.3.0--1, built on 04/02/2010 22:40 GMT > Clients: > /10.17.117.71:37297[1](queued=0,recved=1,sent=0) > Latency min/avg/max: 0/0/0 > Received: 3 > Sent: 2 > Outstanding: 0 > Zxid: 0x20065 > Mode: follower > Node count: 288 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (ZOOKEEPER-851) ZK lets any node to become an observer
[ https://issues.apache.org/jira/browse/ZOOKEEPER-851?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Laxman updated ZOOKEEPER-851: - Assignee: (was: Laxman) > ZK lets any node to become an observer > -- > > Key: ZOOKEEPER-851 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-851 > Project: ZooKeeper > Issue Type: Bug > Components: quorum, server >Affects Versions: 3.3.1 >Reporter: Vishal Kher >Priority: Critical > Fix For: 3.5.0 > > Attachments: ZOOKEEPER-851.patch > > > I had a 3 node cluster running. The zoo.cfg on each contained 3 entries as > show below: > tickTime=2000 > dataDir=/var/zookeeper > clientPort=2181 > initLimit=5 > syncLimit=2 > server.0=10.150.27.61:2888:3888 > server.1=10.150.27.62:2888:3888 > server.2=10.150.27.63:2888:3888 > I wanted to add another node to the cluster. In fourth node's zoo.cfg, I > created another entry for that node and started zk server. The zoo.cfg on the > first 3 nodes was left unchanged. The fourth node was able to join the > cluster even though the 3 nodes had no idea about the fourth node. > zoo.cfg on fourth node: > tickTime=2000 > dataDir=/var/zookeeper > clientPort=2181 > initLimit=5 > syncLimit=2 > server.0=10.150.27.61:2888:3888 > server.1=10.150.27.62:2888:3888 > server.2=10.150.27.63:2888:3888 > server.3=10.17.117.71:2888:3888 > It looks like 10.17.117.71 is becoming an observer in this case. I was > expecting that the leader will reject 10.17.117.71. > # telnet 10.17.117.71 2181 > Trying 10.17.117.71... > Connected to 10.17.117.71. > Escape character is '^]'. > stat > Zookeeper version: 3.3.0--1, built on 04/02/2010 22:40 GMT > Clients: > /10.17.117.71:37297[1](queued=0,recved=1,sent=0) > Latency min/avg/max: 0/0/0 > Received: 3 > Sent: 2 > Outstanding: 0 > Zxid: 0x20065 > Mode: follower > Node count: 288 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (ZOOKEEPER-851) ZK lets any node to become an observer
[ https://issues.apache.org/jira/browse/ZOOKEEPER-851?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mahadev konar updated ZOOKEEPER-851: Fix Version/s: (was: 3.4.0) > ZK lets any node to become an observer > -- > > Key: ZOOKEEPER-851 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-851 > Project: ZooKeeper > Issue Type: Bug > Components: quorum, server >Affects Versions: 3.3.1 >Reporter: Vishal Kher >Assignee: Laxman >Priority: Critical > Fix For: 3.5.0 > > Attachments: ZOOKEEPER-851.patch > > > I had a 3 node cluster running. The zoo.cfg on each contained 3 entries as > show below: > tickTime=2000 > dataDir=/var/zookeeper > clientPort=2181 > initLimit=5 > syncLimit=2 > server.0=10.150.27.61:2888:3888 > server.1=10.150.27.62:2888:3888 > server.2=10.150.27.63:2888:3888 > I wanted to add another node to the cluster. In fourth node's zoo.cfg, I > created another entry for that node and started zk server. The zoo.cfg on the > first 3 nodes was left unchanged. The fourth node was able to join the > cluster even though the 3 nodes had no idea about the fourth node. > zoo.cfg on fourth node: > tickTime=2000 > dataDir=/var/zookeeper > clientPort=2181 > initLimit=5 > syncLimit=2 > server.0=10.150.27.61:2888:3888 > server.1=10.150.27.62:2888:3888 > server.2=10.150.27.63:2888:3888 > server.3=10.17.117.71:2888:3888 > It looks like 10.17.117.71 is becoming an observer in this case. I was > expecting that the leader will reject 10.17.117.71. > # telnet 10.17.117.71 2181 > Trying 10.17.117.71... > Connected to 10.17.117.71. > Escape character is '^]'. > stat > Zookeeper version: 3.3.0--1, built on 04/02/2010 22:40 GMT > Clients: > /10.17.117.71:37297[1](queued=0,recved=1,sent=0) > Latency min/avg/max: 0/0/0 > Received: 3 > Sent: 2 > Outstanding: 0 > Zxid: 0x20065 > Mode: follower > Node count: 288 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (ZOOKEEPER-851) ZK lets any node to become an observer
[ https://issues.apache.org/jira/browse/ZOOKEEPER-851?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Laxman updated ZOOKEEPER-851: - Attachment: ZOOKEEPER-851.patch > ZK lets any node to become an observer > -- > > Key: ZOOKEEPER-851 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-851 > Project: ZooKeeper > Issue Type: Bug > Components: quorum, server >Affects Versions: 3.3.1 >Reporter: Vishal Kher >Assignee: Laxman >Priority: Critical > Fix For: 3.5.0 > > Attachments: ZOOKEEPER-851.patch > > > I had a 3 node cluster running. The zoo.cfg on each contained 3 entries as > show below: > tickTime=2000 > dataDir=/var/zookeeper > clientPort=2181 > initLimit=5 > syncLimit=2 > server.0=10.150.27.61:2888:3888 > server.1=10.150.27.62:2888:3888 > server.2=10.150.27.63:2888:3888 > I wanted to add another node to the cluster. In fourth node's zoo.cfg, I > created another entry for that node and started zk server. The zoo.cfg on the > first 3 nodes was left unchanged. The fourth node was able to join the > cluster even though the 3 nodes had no idea about the fourth node. > zoo.cfg on fourth node: > tickTime=2000 > dataDir=/var/zookeeper > clientPort=2181 > initLimit=5 > syncLimit=2 > server.0=10.150.27.61:2888:3888 > server.1=10.150.27.62:2888:3888 > server.2=10.150.27.63:2888:3888 > server.3=10.17.117.71:2888:3888 > It looks like 10.17.117.71 is becoming an observer in this case. I was > expecting that the leader will reject 10.17.117.71. > # telnet 10.17.117.71 2181 > Trying 10.17.117.71... > Connected to 10.17.117.71. > Escape character is '^]'. > stat > Zookeeper version: 3.3.0--1, built on 04/02/2010 22:40 GMT > Clients: > /10.17.117.71:37297[1](queued=0,recved=1,sent=0) > Latency min/avg/max: 0/0/0 > Received: 3 > Sent: 2 > Outstanding: 0 > Zxid: 0x20065 > Mode: follower > Node count: 288 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (ZOOKEEPER-851) ZK lets any node to become an observer
[ https://issues.apache.org/jira/browse/ZOOKEEPER-851?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mahadev konar updated ZOOKEEPER-851: Fix Version/s: (was: 3.4.0) 3.5.0 not a blocker. Moving it out of 3.4 release. > ZK lets any node to become an observer > -- > > Key: ZOOKEEPER-851 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-851 > Project: ZooKeeper > Issue Type: Bug > Components: quorum, server >Affects Versions: 3.3.1 >Reporter: Vishal K >Priority: Critical > Fix For: 3.5.0 > > > I had a 3 node cluster running. The zoo.cfg on each contained 3 entries as > show below: > tickTime=2000 > dataDir=/var/zookeeper > clientPort=2181 > initLimit=5 > syncLimit=2 > server.0=10.150.27.61:2888:3888 > server.1=10.150.27.62:2888:3888 > server.2=10.150.27.63:2888:3888 > I wanted to add another node to the cluster. In fourth node's zoo.cfg, I > created another entry for that node and started zk server. The zoo.cfg on the > first 3 nodes was left unchanged. The fourth node was able to join the > cluster even though the 3 nodes had no idea about the fourth node. > zoo.cfg on fourth node: > tickTime=2000 > dataDir=/var/zookeeper > clientPort=2181 > initLimit=5 > syncLimit=2 > server.0=10.150.27.61:2888:3888 > server.1=10.150.27.62:2888:3888 > server.2=10.150.27.63:2888:3888 > server.3=10.17.117.71:2888:3888 > It looks like 10.17.117.71 is becoming an observer in this case. I was > expecting that the leader will reject 10.17.117.71. > # telnet 10.17.117.71 2181 > Trying 10.17.117.71... > Connected to 10.17.117.71. > Escape character is '^]'. > stat > Zookeeper version: 3.3.0--1, built on 04/02/2010 22:40 GMT > Clients: > /10.17.117.71:37297[1](queued=0,recved=1,sent=0) > Latency min/avg/max: 0/0/0 > Received: 3 > Sent: 2 > Outstanding: 0 > Zxid: 0x20065 > Mode: follower > Node count: 288 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
