[jira] Updated: (ZOOKEEPER-151) Document change to server configuration
[ https://issues.apache.org/jira/browse/ZOOKEEPER-151?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Flavio Paiva Junqueira updated ZOOKEEPER-151: - Status: Open (was: Patch Available) The current patch updates the documentation to explain how to configure a set of ZooKeeper servers with the default leader election. This description eliminates the old way of configuring that works with the original leader election algorithm, though. Although the new way of configuring should also work with the original leader election, it would be misleading to configure another port and not use it. Since we have currently two implementations (there are two more, but we've been focusing on two), and they require different ways of configuring the servers, I wonder if we should support both. Also, if we have different ways of configuring, then to have both ways enabled, we would need to have both "electionAlg" and server specs to determine if the configuration is correct, thus creating a dependency between parameters. It is probably best to create another jira to discuss the configuration issue, and leave this one for documentation. For now, I'm canceling this patch, and once we decide upon server configuration, I can come back to this issue and update the patch. > Document change to server configuration > --- > > Key: ZOOKEEPER-151 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-151 > Project: Zookeeper > Issue Type: Bug >Affects Versions: 3.0.0 >Reporter: Flavio Paiva Junqueira >Assignee: Flavio Paiva Junqueira > Fix For: 3.0.0 > > Attachments: ZOOKEEPER-151.patch > > > The patch of jira 127 changed the format of server configuration files, but > it didn't change the documentation. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-158) Leader and followers increase cpu utilization upon loss of a follower
[ https://issues.apache.org/jira/browse/ZOOKEEPER-158?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Flavio Paiva Junqueira updated ZOOKEEPER-158: - Attachment: dead-follower.tar.gz Attaching logs provided by Stu Hood (copying from JIRA 157). > Leader and followers increase cpu utilization upon loss of a follower > - > > Key: ZOOKEEPER-158 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-158 > Project: Zookeeper > Issue Type: Improvement > Components: quorum >Reporter: Flavio Paiva Junqueira >Priority: Minor > Attachments: dead-follower.tar.gz > > > In a set of ZooKeeper servers, when there is a leader operation and supported > by a quorum of servers, we have observed that cpu utilization increases > substantially once a follower fails or disconnects. Stu Hood provided logs > showing this behavior. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (ZOOKEEPER-158) Leader and followers increase cpu utilization upon loss of a follower
Leader and followers increase cpu utilization upon loss of a follower - Key: ZOOKEEPER-158 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-158 Project: Zookeeper Issue Type: Improvement Components: quorum Reporter: Flavio Paiva Junqueira Priority: Minor In a set of ZooKeeper servers, when there is a leader operation and supported by a quorum of servers, we have observed that cpu utilization increases substantially once a follower fails or disconnects. Stu Hood provided logs showing this behavior. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-157) Peer can't find existing leader
[ https://issues.apache.org/jira/browse/ZOOKEEPER-157?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Flavio Paiva Junqueira updated ZOOKEEPER-157: - Resolution: Fixed Status: Resolved (was: Patch Available) Thanks, Ben, for reviewing it so fast! Thanks, Stu, for you feedback! I'll open a jira for the cpu issue you pointed out. > Peer can't find existing leader > --- > > Key: ZOOKEEPER-157 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-157 > Project: Zookeeper > Issue Type: Bug >Affects Versions: 3.0.0 >Reporter: Flavio Paiva Junqueira >Assignee: Flavio Paiva Junqueira >Priority: Critical > Attachments: dead-follower.tar.gz, ZOOKEEPER-157.patch > > > In the patch of JIRA 127, I forgot to set the state of a peer when this peer > is looking for a leader and it receives a message from the current leader. In > this patch, I have fixed this problem, and also returned to what we had > previously. With this current patch, when a peer joins and there is already a > leader elected, the joining peer will only recognize the new leader as the > leader once it receives a confirmation from a majority. The alternative is to > set the leader once we receive a message from a peer claiming to be the > leader (what we have on trunk now, although broken because we don't set the > state of the peer), but there could be cases in which a peer believes to be > leader, although it is not the leader any longer, and the joining peer would > select this false leader to be its leader. Eventually, the false leader would > timeout, and both processes would select the correct leader. This small fix > gets rid of such problems, though. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-157) Peer can't find existing leader
[ https://issues.apache.org/jira/browse/ZOOKEEPER-157?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12636885#action_12636885 ] Hudson commented on ZOOKEEPER-157: -- Integrated in ZooKeeper-trunk #104 (See [http://hudson.zones.apache.org/hudson/job/ZooKeeper-trunk/104/]) .patch > Peer can't find existing leader > --- > > Key: ZOOKEEPER-157 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-157 > Project: Zookeeper > Issue Type: Bug >Affects Versions: 3.0.0 >Reporter: Flavio Paiva Junqueira >Assignee: Flavio Paiva Junqueira >Priority: Critical > Attachments: dead-follower.tar.gz, ZOOKEEPER-157.patch > > > In the patch of JIRA 127, I forgot to set the state of a peer when this peer > is looking for a leader and it receives a message from the current leader. In > this patch, I have fixed this problem, and also returned to what we had > previously. With this current patch, when a peer joins and there is already a > leader elected, the joining peer will only recognize the new leader as the > leader once it receives a confirmation from a majority. The alternative is to > set the leader once we receive a message from a peer claiming to be the > leader (what we have on trunk now, although broken because we don't set the > state of the peer), but there could be cases in which a peer believes to be > leader, although it is not the leader any longer, and the joining peer would > select this false leader to be its leader. Eventually, the false leader would > timeout, and both processes would select the correct leader. This small fix > gets rid of such problems, though. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
