[jira] Resolved: (ZOOKEEPER-769) Leader can treat observers as quorum members
[ https://issues.apache.org/jira/browse/ZOOKEEPER-769?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Doroshenko resolved ZOOKEEPER-769. - Resolution: Not A Problem Henry, you're right. I overlooked to add peerType. Anyway, wouldn't it be better if server warned about such inconsistency in a config? It can infer from servers list that it should be an observer, so it could either WARN in logs that peerType=observer is missing, or just make itself an observer. Leader can treat observers as quorum members Key: ZOOKEEPER-769 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-769 Project: Zookeeper Issue Type: Bug Affects Versions: 3.3.0 Environment: Ubuntu Karmic x64 Reporter: Sergey Doroshenko Fix For: 3.3.0 Attachments: follower.log, leader.log, observer.log, zoo1.cfg In short: it seems leader can treat observers as quorum members. Steps to repro: 1. Server configuration: 3 voters, 2 observers (attached). 2. Bring up 2 voters and one observer. It's enough for quorum. 3. Shut down the one from the quorum who is the follower. As I understand, expected result is that leader will start a new election round so that to regain quorum. But the real situation is that it just says goodbye to that follower, and is still operable. (When I'm shutting down 3rd one -- observer -- leader starts trying to regain a quorum). (Expectedly, if on step 3 we shut down the leader, not the follower, remaining follower starta new leader election, as it should be). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-769) Leader can treat observers as quorum members
[ https://issues.apache.org/jira/browse/ZOOKEEPER-769?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Doroshenko updated ZOOKEEPER-769: Attachment: warning.patch Simple patch as per my suggestion above. (In git format. LMK if it's not acceptable.) Leader can treat observers as quorum members Key: ZOOKEEPER-769 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-769 Project: Zookeeper Issue Type: Bug Affects Versions: 3.3.0 Environment: Ubuntu Karmic x64 Reporter: Sergey Doroshenko Fix For: 3.3.0 Attachments: follower.log, leader.log, observer.log, warning.patch, zoo1.cfg In short: it seems leader can treat observers as quorum members. Steps to repro: 1. Server configuration: 3 voters, 2 observers (attached). 2. Bring up 2 voters and one observer. It's enough for quorum. 3. Shut down the one from the quorum who is the follower. As I understand, expected result is that leader will start a new election round so that to regain quorum. But the real situation is that it just says goodbye to that follower, and is still operable. (When I'm shutting down 3rd one -- observer -- leader starts trying to regain a quorum). (Expectedly, if on step 3 we shut down the leader, not the follower, remaining follower starta new leader election, as it should be). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-769) Leader can treat observers as quorum members
[ https://issues.apache.org/jira/browse/ZOOKEEPER-769?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Hunt updated ZOOKEEPER-769: --- Assignee: Sergey Doroshenko Fix Version/s: 3.4.0 (was: 3.3.0) Leader can treat observers as quorum members Key: ZOOKEEPER-769 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-769 Project: Zookeeper Issue Type: Bug Affects Versions: 3.3.0 Environment: Ubuntu Karmic x64 Reporter: Sergey Doroshenko Assignee: Sergey Doroshenko Fix For: 3.4.0 Attachments: follower.log, leader.log, observer.log, warning.patch, zoo1.cfg In short: it seems leader can treat observers as quorum members. Steps to repro: 1. Server configuration: 3 voters, 2 observers (attached). 2. Bring up 2 voters and one observer. It's enough for quorum. 3. Shut down the one from the quorum who is the follower. As I understand, expected result is that leader will start a new election round so that to regain quorum. But the real situation is that it just says goodbye to that follower, and is still operable. (When I'm shutting down 3rd one -- observer -- leader starts trying to regain a quorum). (Expectedly, if on step 3 we shut down the leader, not the follower, remaining follower starta new leader election, as it should be). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Reopened: (ZOOKEEPER-769) Leader can treat observers as quorum members
[ https://issues.apache.org/jira/browse/ZOOKEEPER-769?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Hunt reopened ZOOKEEPER-769: reopening to improve the config parsing Leader can treat observers as quorum members Key: ZOOKEEPER-769 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-769 Project: Zookeeper Issue Type: Bug Affects Versions: 3.3.0 Environment: Ubuntu Karmic x64 Reporter: Sergey Doroshenko Assignee: Sergey Doroshenko Fix For: 3.4.0 Attachments: follower.log, leader.log, observer.log, warning.patch, zoo1.cfg In short: it seems leader can treat observers as quorum members. Steps to repro: 1. Server configuration: 3 voters, 2 observers (attached). 2. Bring up 2 voters and one observer. It's enough for quorum. 3. Shut down the one from the quorum who is the follower. As I understand, expected result is that leader will start a new election round so that to regain quorum. But the real situation is that it just says goodbye to that follower, and is still operable. (When I'm shutting down 3rd one -- observer -- leader starts trying to regain a quorum). (Expectedly, if on step 3 we shut down the leader, not the follower, remaining follower starta new leader election, as it should be). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-769) Leader can treat observers as quorum members
[ https://issues.apache.org/jira/browse/ZOOKEEPER-769?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12865234#action_12865234 ] Patrick Hunt commented on ZOOKEEPER-769: Hi Sergey, thanks for the patch, see this page for details on contributing: http://wiki.apache.org/hadoop/ZooKeeper/HowToContribute git is fine, but you need to use the --no-prefix option when doing the diff, otw the patch will fail with the automated verification of the patch. also, in future it's good to name the patch after the jira ie ZOOKEEPER-769.patch, it helps reviewers and makes easier to keep track of many patches. Regards. Leader can treat observers as quorum members Key: ZOOKEEPER-769 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-769 Project: Zookeeper Issue Type: Bug Affects Versions: 3.3.0 Environment: Ubuntu Karmic x64 Reporter: Sergey Doroshenko Assignee: Sergey Doroshenko Fix For: 3.4.0 Attachments: follower.log, leader.log, observer.log, warning.patch, zoo1.cfg In short: it seems leader can treat observers as quorum members. Steps to repro: 1. Server configuration: 3 voters, 2 observers (attached). 2. Bring up 2 voters and one observer. It's enough for quorum. 3. Shut down the one from the quorum who is the follower. As I understand, expected result is that leader will start a new election round so that to regain quorum. But the real situation is that it just says goodbye to that follower, and is still operable. (When I'm shutting down 3rd one -- observer -- leader starts trying to regain a quorum). (Expectedly, if on step 3 we shut down the leader, not the follower, remaining follower starta new leader election, as it should be). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-769) Leader can treat observers as quorum members
[ https://issues.apache.org/jira/browse/ZOOKEEPER-769?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12865240#action_12865240 ] Henry Robinson commented on ZOOKEEPER-769: -- Sergey - Great, thanks for making this patch! ISTR there was some reason why we didn't infer peerType from the servers list, but I can't remember what it was... As for your patch, a few small comments: 1. Use --no-prefix and just attach the output of git-diff (no mail headers etc) - Hudson is rather picky about the patch formats it can apply 2. It would be great to include a test that reads a configuration and checks that the behaviour is correct 3. If the peerTypes don't match up, should we default to the server list (on the assumption that that will be consistent across all servers)? 4. Once you've added the patch, click 'submit patch' to start Hudson moving. cheers, Henry Leader can treat observers as quorum members Key: ZOOKEEPER-769 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-769 Project: Zookeeper Issue Type: Bug Affects Versions: 3.3.0 Environment: Ubuntu Karmic x64 Reporter: Sergey Doroshenko Assignee: Sergey Doroshenko Fix For: 3.4.0 Attachments: follower.log, leader.log, observer.log, warning.patch, zoo1.cfg In short: it seems leader can treat observers as quorum members. Steps to repro: 1. Server configuration: 3 voters, 2 observers (attached). 2. Bring up 2 voters and one observer. It's enough for quorum. 3. Shut down the one from the quorum who is the follower. As I understand, expected result is that leader will start a new election round so that to regain quorum. But the real situation is that it just says goodbye to that follower, and is still operable. (When I'm shutting down 3rd one -- observer -- leader starts trying to regain a quorum). (Expectedly, if on step 3 we shut down the leader, not the follower, remaining follower starta new leader election, as it should be). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-587) client should log timeout negotiated with server
[ https://issues.apache.org/jira/browse/ZOOKEEPER-587?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Hunt updated ZOOKEEPER-587: --- Labels: logging (was: ) client should log timeout negotiated with server Key: ZOOKEEPER-587 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-587 Project: Zookeeper Issue Type: Bug Components: c client, java client Affects Versions: 3.2.1 Reporter: Patrick Hunt Assignee: Patrick Hunt Fix For: 3.3.0 Attachments: ZOOKEEPER-587.patch, ZOOKEEPER-587.patch The ZK client should log the timeout negotiated with the server if the time is different than the timeout parameter specified by the client. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Contributing code that pulls in code with non-Apache license
Hi guys, I'm looking at submitting a first drop of the log grapher some of you have seen. However, the drawing depends on a couple of javascript libraries which are MIT and BSD licensed and some other java libraries, org.restlet.jar and json.jar. The restlets shouldn't be a problem since there's a maven repo for it, so I should be able to pull it in through java. However json.jar has a Do whatever you like as long as you keep this license license? How have you dealt with these issues in the past if you've come across them? Regards Ivan
Re: Contributing code that pulls in code with non-Apache license
Licenses that are specified as Category A (incl mit/bsd) are fine: http://www.apache.org/legal/3party.html Something like json.jar you should include the license alongside the jar file (see what we do in src/java/lib for jline as an example). Patrick On 05/07/2010 10:54 AM, Ivan Kelly wrote: Hi guys, I'm looking at submitting a first drop of the log grapher some of you have seen. However, the drawing depends on a couple of javascript libraries which are MIT and BSD licensed and some other java libraries, org.restlet.jar and json.jar. The restlets shouldn't be a problem since there's a maven repo for it, so I should be able to pull it in through java. However json.jar has a Do whatever you like as long as you keep this license license? How have you dealt with these issues in the past if you've come across them? Regards Ivan
[VOTE] Release ZooKeeper 3.3.1 (candidate 0)
I've created a candidate build for ZooKeeper 3.3.1. This is a bug fix release addressing seventeen issues (one critical) -- see the release notes for details. *** Please download, test and VOTE before the *** vote closes 11am pacific time, Wednesday, May 12.*** http://people.apache.org/~phunt/zookeeper-3.3.1-candidate-0/ Should we release this? Patrick
Re: Contributing code that pulls in code with non-Apache license
If it's the infamous json.org stuff from crockford with the not evil license, then please don't use it: https://issues.apache.org/jira/browse/HBASE-2383 Thomas Patrick Hunt: Licenses that are specified as Category A (incl mit/bsd) are fine: http://www.apache.org/legal/3party.html Something like json.jar you should include the license alongside the jar file (see what we do in src/java/lib for jline as an example). Patrick On 05/07/2010 10:54 AM, Ivan Kelly wrote: Hi guys, I'm looking at submitting a first drop of the log grapher some of you have seen. However, the drawing depends on a couple of javascript libraries which are MIT and BSD licensed and some other java libraries, org.restlet.jar and json.jar. The restlets shouldn't be a problem since there's a maven repo for it, so I should be able to pull it in through java. However json.jar has a Do whatever you like as long as you keep this license license? How have you dealt with these issues in the past if you've come across them? Regards Ivan Thomas Koch, http://www.koch.ro
[jira] Created: (ZOOKEEPER-771) zkpython return without exception set on invalid auth scheme
zkpython return without exception set on invalid auth scheme Key: ZOOKEEPER-771 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-771 Project: Zookeeper Issue Type: Bug Components: contrib-bindings Environment: ubuntu lucid Reporter: Kapil Thangavelu If you attempt to utilize an invalid auth scheme when adding authentication, you'll end up with an error return value in your callback. But the handle itself will be hosed, attempting to utilize it with any part of the api will return SystemError: error return without exception set -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-771) zkpython return without exception set on invalid auth scheme
[ https://issues.apache.org/jira/browse/ZOOKEEPER-771?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kapil Thangavelu updated ZOOKEEPER-771: --- Attachment: autherrorreturn.py sample script that reproduces the error. zkpython return without exception set on invalid auth scheme Key: ZOOKEEPER-771 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-771 Project: Zookeeper Issue Type: Bug Components: contrib-bindings Environment: ubuntu lucid Reporter: Kapil Thangavelu Attachments: autherrorreturn.py If you attempt to utilize an invalid auth scheme when adding authentication, you'll end up with an error return value in your callback. But the handle itself will be hosed, attempting to utilize it with any part of the api will return SystemError: error return without exception set -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-771) zkpython return without exception set on invalid auth scheme
[ https://issues.apache.org/jira/browse/ZOOKEEPER-771?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kapil Thangavelu updated ZOOKEEPER-771: --- Priority: Minor (was: Major) zkpython return without exception set on invalid auth scheme Key: ZOOKEEPER-771 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-771 Project: Zookeeper Issue Type: Bug Components: contrib-bindings Environment: ubuntu lucid Reporter: Kapil Thangavelu Priority: Minor Attachments: autherrorreturn.py If you attempt to utilize an invalid auth scheme when adding authentication, you'll end up with an error return value in your callback. But the handle itself will be hosed, attempting to utilize it with any part of the api will return SystemError: error return without exception set -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-769) Leader can treat observers as quorum members
[ https://issues.apache.org/jira/browse/ZOOKEEPER-769?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Doroshenko updated ZOOKEEPER-769: Status: Patch Available (was: Reopened) Leader can treat observers as quorum members Key: ZOOKEEPER-769 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-769 Project: Zookeeper Issue Type: Bug Affects Versions: 3.3.0 Environment: Ubuntu Karmic x64 Reporter: Sergey Doroshenko Assignee: Sergey Doroshenko Fix For: 3.4.0 Attachments: follower.log, leader.log, observer.log, warning.patch, zoo1.cfg, ZOOKEEPER-769.patch In short: it seems leader can treat observers as quorum members. Steps to repro: 1. Server configuration: 3 voters, 2 observers (attached). 2. Bring up 2 voters and one observer. It's enough for quorum. 3. Shut down the one from the quorum who is the follower. As I understand, expected result is that leader will start a new election round so that to regain quorum. But the real situation is that it just says goodbye to that follower, and is still operable. (When I'm shutting down 3rd one -- observer -- leader starts trying to regain a quorum). (Expectedly, if on step 3 we shut down the leader, not the follower, remaining follower starta new leader election, as it should be). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-769) Leader can treat observers as quorum members
[ https://issues.apache.org/jira/browse/ZOOKEEPER-769?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12865331#action_12865331 ] Hadoop QA commented on ZOOKEEPER-769: - +1 overall. Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12444000/ZOOKEEPER-769.patch against trunk revision 941521. +1 @author. The patch does not contain any @author tags. +1 tests included. The patch appears to include 3 new or modified tests. +1 javadoc. The javadoc tool did not generate any warning messages. +1 javac. The applied patch does not increase the total number of javac compiler warnings. +1 findbugs. The patch does not introduce any new Findbugs warnings. +1 release audit. The applied patch does not increase the total number of release audit warnings. +1 core tests. The patch passed core unit tests. +1 contrib tests. The patch passed contrib unit tests. Test results: http://hudson.zones.apache.org/hudson/job/Zookeeper-Patch-h1.grid.sp2.yahoo.net/87/testReport/ Findbugs warnings: http://hudson.zones.apache.org/hudson/job/Zookeeper-Patch-h1.grid.sp2.yahoo.net/87/artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html Console output: http://hudson.zones.apache.org/hudson/job/Zookeeper-Patch-h1.grid.sp2.yahoo.net/87/console This message is automatically generated. Leader can treat observers as quorum members Key: ZOOKEEPER-769 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-769 Project: Zookeeper Issue Type: Bug Affects Versions: 3.3.0 Environment: Ubuntu Karmic x64 Reporter: Sergey Doroshenko Assignee: Sergey Doroshenko Fix For: 3.4.0 Attachments: follower.log, leader.log, observer.log, warning.patch, zoo1.cfg, ZOOKEEPER-769.patch In short: it seems leader can treat observers as quorum members. Steps to repro: 1. Server configuration: 3 voters, 2 observers (attached). 2. Bring up 2 voters and one observer. It's enough for quorum. 3. Shut down the one from the quorum who is the follower. As I understand, expected result is that leader will start a new election round so that to regain quorum. But the real situation is that it just says goodbye to that follower, and is still operable. (When I'm shutting down 3rd one -- observer -- leader starts trying to regain a quorum). (Expectedly, if on step 3 we shut down the leader, not the follower, remaining follower starta new leader election, as it should be). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-679) Offers a node design for interacting with the Java Zookeeper client.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12865354#action_12865354 ] Chris K Wensel commented on ZOOKEEPER-679: -- wondering if this would be better served as a github project so it can be collaborated on much easier. Offers a node design for interacting with the Java Zookeeper client. Key: ZOOKEEPER-679 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-679 Project: Zookeeper Issue Type: New Feature Components: contrib, java client, tests Reporter: Aaron Crow Assignee: Aaron Crow Fix For: 3.4.0 Attachments: ZOOKEEPER-679.patch, ZOOKEEPER-679.patch, ZOOKEEPER-679.patch, ZOOKEEPER-679.patch Following up on my conversations with Patrick and Mahadev (http://n2.nabble.com/Might-I-contribute-a-Node-design-for-the-Java-API-td4567695.html#a4567695). This patch includes the implementation as well as unit tests. The first unit test gives a simple high level demo of using the node API. The current implementation is simple and is only what I need withe current project I am working on. However, I am very open to any and all suggestions for improvement. This is a proposal to support a simplified node (or File) like API into a Zookeeper tree, by wrapping the Zookeeper Java client. It is similar to Java's File API design. Although, I'm trying to make it easier in a few spots. For example, deleting a Node recursively is done by default. I also lean toward resolving Exceptions under the hood when it seems appropriate. For example, if you ask a Node if it exists, and its parent doesn't even exist, you just get a false back (rather than a nasty Exception). As for watches and ephemeral nodes, my current work does not need these things so I currently have no handling of them. But if potential users of the Node a.k.a. File design want these things, I'd be open to supporting them as reasonable. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
