[jira] Updated: (ZOOKEEPER-609) ObserverTest failure zk should not be connected expected not same
[ https://issues.apache.org/jira/browse/ZOOKEEPER-609?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henry Robinson updated ZOOKEEPER-609: - Status: Patch Available (was: Open) ObserverTest failure zk should not be connected expected not same --- Key: ZOOKEEPER-609 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-609 Project: Zookeeper Issue Type: Bug Components: quorum, server Affects Versions: 3.3.0 Reporter: Patrick Hunt Assignee: Henry Robinson Priority: Blocker Fix For: 3.3.0 Attachments: TEST-org.apache.zookeeper.server.quorum.ObserverTest.xml, ZOOKEEPER-609.patch ObserverTest failed running on 8core I ran the test as: ant -Dtest.junit.output.format=xml -Dtest.output -Dtestcase=AsyncHammerTest clean test-core-java test.out -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-609) ObserverTest failure zk should not be connected expected not same
[ https://issues.apache.org/jira/browse/ZOOKEEPER-609?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12791270#action_12791270 ] Hadoop QA commented on ZOOKEEPER-609: - +1 overall. Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12428141/ZOOKEEPER-609.patch against trunk revision 891034. +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-h7.grid.sp2.yahoo.net/27/testReport/ Findbugs warnings: http://hudson.zones.apache.org/hudson/job/Zookeeper-Patch-h7.grid.sp2.yahoo.net/27/artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html Console output: http://hudson.zones.apache.org/hudson/job/Zookeeper-Patch-h7.grid.sp2.yahoo.net/27/console This message is automatically generated. ObserverTest failure zk should not be connected expected not same --- Key: ZOOKEEPER-609 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-609 Project: Zookeeper Issue Type: Bug Components: quorum, server Affects Versions: 3.3.0 Reporter: Patrick Hunt Assignee: Henry Robinson Priority: Blocker Fix For: 3.3.0 Attachments: TEST-org.apache.zookeeper.server.quorum.ObserverTest.xml, ZOOKEEPER-609.patch ObserverTest failed running on 8core I ran the test as: ant -Dtest.junit.output.format=xml -Dtest.output -Dtestcase=AsyncHammerTest clean test-core-java test.out -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-630) Trunk has duplicate ObserverTest.java files
[ https://issues.apache.org/jira/browse/ZOOKEEPER-630?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12791308#action_12791308 ] Hadoop QA commented on ZOOKEEPER-630: - +1 overall. Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12428137/ZOOKEEPER-630.patch against trunk revision 891034. +1 @author. The patch does not contain any @author tags. +1 tests included. The patch appears to include 2 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-h8.grid.sp2.yahoo.net/89/testReport/ Findbugs warnings: http://hudson.zones.apache.org/hudson/job/Zookeeper-Patch-h8.grid.sp2.yahoo.net/89/artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html Console output: http://hudson.zones.apache.org/hudson/job/Zookeeper-Patch-h8.grid.sp2.yahoo.net/89/console This message is automatically generated. Trunk has duplicate ObserverTest.java files --- Key: ZOOKEEPER-630 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-630 Project: Zookeeper Issue Type: Bug Components: tests Reporter: Henry Robinson Assignee: Henry Robinson Attachments: ZOOKEEPER-630.patch There are two identical ObserverTest.java files in trunk. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-486) Improve bookie performance for large number of ledgers
[ https://issues.apache.org/jira/browse/ZOOKEEPER-486?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Flavio Paiva Junqueira updated ZOOKEEPER-486: - Status: Open (was: Patch Available) Ben, this patch is broken. It is missing a few classes, like LedgerCache and LedgerEntryPage. Improve bookie performance for large number of ledgers -- Key: ZOOKEEPER-486 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-486 Project: Zookeeper Issue Type: Improvement Components: contrib-bookkeeper Reporter: Flavio Paiva Junqueira Assignee: Benjamin Reed Attachments: ZOOKEEPER-486.patch, ZOOKEEPER-486.patch, ZOOKEEPER-486.patch If we write simultaneously to a large number of ledgers on a bookie, then performance drops significantly due to more seeks on the ledger device. In such cases, we should be clustering ledgers into files to reduce the number of seeks, and performing sequential writes on each file. Clustering ledgers will impact read performance, so we would to have a knob to control such a feature. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-627) zkpython arbitrarily restricts the size of a 'get' to 512 bytes
[ https://issues.apache.org/jira/browse/ZOOKEEPER-627?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12791353#action_12791353 ] Gustavo Niemeyer commented on ZOOKEEPER-627: Thanks for the fix Henry. I think there's a minor detail to sort out before merging it: it looks like the buffer is being freed before it's actually used to build the return value. zkpython arbitrarily restricts the size of a 'get' to 512 bytes --- Key: ZOOKEEPER-627 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-627 Project: Zookeeper Issue Type: Bug Components: contrib-bindings Reporter: Henry Robinson Assignee: Henry Robinson Attachments: ZOOKEEPER-627.patch Reported on the list: I'm working on using ZooKeeper for an internal application at Digg. I've been using the zkpython package and I just noticed that the data I was receiving from a zookeeper.get() call was being truncated. After some quick digging I found that zookeeper.c limits the data returned to 512 characters (see http://svn.apache.org/viewvc/hadoop/zookeeper/tags/release-3.2.2/src/contrib/zkpython/src/c/zookeeper.c?view=markup line 855). Is there a reason for this? The only information regarding node size that I've read is that it should not exceed 1MB so this limit seems a bit arbitrary and restrictive. Thanks for the great work! Rich -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-629) FLELostMessageTest assumes that the first zxid on a startup of quorum is -1.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-629?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Flavio Paiva Junqueira updated ZOOKEEPER-629: - Attachment: ZOOKEEPER-629.patch This patches fixes this issue. FLELostMessageTest assumes that the first zxid on a startup of quorum is -1. Key: ZOOKEEPER-629 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-629 Project: Zookeeper Issue Type: Bug Reporter: Mahadev konar Fix For: 3.3.0 Attachments: ZOOKEEPER-629.patch FLELostMessageTest assumes that the first zxid exchange will be -1 zxid. WIth ZOOKEEPER-596 the zxid would be 0 and not -1. So the corresponding change needs to be made to this test. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-629) FLELostMessageTest assumes that the first zxid on a startup of quorum is -1.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-629?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Flavio Paiva Junqueira updated ZOOKEEPER-629: - Assignee: Flavio Paiva Junqueira Status: Patch Available (was: Open) FLELostMessageTest assumes that the first zxid on a startup of quorum is -1. Key: ZOOKEEPER-629 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-629 Project: Zookeeper Issue Type: Bug Reporter: Mahadev konar Assignee: Flavio Paiva Junqueira Fix For: 3.3.0 Attachments: ZOOKEEPER-629.patch FLELostMessageTest assumes that the first zxid exchange will be -1 zxid. WIth ZOOKEEPER-596 the zxid would be 0 and not -1. So the corresponding change needs to be made to this test. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-506) QuorumBase should use default leader election
[ https://issues.apache.org/jira/browse/ZOOKEEPER-506?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12791407#action_12791407 ] Hudson commented on ZOOKEEPER-506: -- Integrated in ZooKeeper-trunk #628 (See [http://hudson.zones.apache.org/hudson/job/ZooKeeper-trunk/628/]) ZOOKEEPER-599. Changes to FLE and QuorumCnxManager to support Observers . QuorumBase should use default leader election QuorumBase should use default leader election - Key: ZOOKEEPER-506 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-506 Project: Zookeeper Issue Type: Improvement Components: leaderElection Reporter: Flavio Paiva Junqueira Assignee: Flavio Paiva Junqueira Fix For: 3.3.0 QuorumBase currently does not use the default implementation of leader election. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-599) Changes to FLE and QuorumCnxManager to support Observers
[ https://issues.apache.org/jira/browse/ZOOKEEPER-599?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12791406#action_12791406 ] Hudson commented on ZOOKEEPER-599: -- Integrated in ZooKeeper-trunk #628 (See [http://hudson.zones.apache.org/hudson/job/ZooKeeper-trunk/628/]) . Changes to FLE and QuorumCnxManager to support Observers ZOOKEEPER-506. QuorumBase should use default leader election Changes to FLE and QuorumCnxManager to support Observers Key: ZOOKEEPER-599 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-599 Project: Zookeeper Issue Type: Improvement Reporter: Flavio Paiva Junqueira Assignee: Flavio Paiva Junqueira Fix For: 3.3.0 Attachments: ZOOKEEPER-599.patch, ZOOKEEPER-599.patch, ZOOKEEPER-599.patch, ZOOKEEPER-599.patch Observers currently can only use electionAlg 0, which is not the default, supported leader implementation. This issue will fix it. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-629) FLELostMessageTest assumes that the first zxid on a startup of quorum is -1.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-629?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12791419#action_12791419 ] Hadoop QA commented on ZOOKEEPER-629: - -1 overall. Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12428164/ZOOKEEPER-629.patch against trunk revision 891034. +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 failed core unit tests. +1 contrib tests. The patch passed contrib unit tests. Test results: http://hudson.zones.apache.org/hudson/job/Zookeeper-Patch-h8.grid.sp2.yahoo.net/90/testReport/ Findbugs warnings: http://hudson.zones.apache.org/hudson/job/Zookeeper-Patch-h8.grid.sp2.yahoo.net/90/artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html Console output: http://hudson.zones.apache.org/hudson/job/Zookeeper-Patch-h8.grid.sp2.yahoo.net/90/console This message is automatically generated. FLELostMessageTest assumes that the first zxid on a startup of quorum is -1. Key: ZOOKEEPER-629 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-629 Project: Zookeeper Issue Type: Bug Reporter: Mahadev konar Assignee: Flavio Paiva Junqueira Fix For: 3.3.0 Attachments: ZOOKEEPER-629.patch FLELostMessageTest assumes that the first zxid exchange will be -1 zxid. WIth ZOOKEEPER-596 the zxid would be 0 and not -1. So the corresponding change needs to be made to this test. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-627) zkpython arbitrarily restricts the size of a 'get' to 512 bytes
[ https://issues.apache.org/jira/browse/ZOOKEEPER-627?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henry Robinson updated ZOOKEEPER-627: - Attachment: ZOOKEEPER-627.patch zkpython arbitrarily restricts the size of a 'get' to 512 bytes --- Key: ZOOKEEPER-627 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-627 Project: Zookeeper Issue Type: Bug Components: contrib-bindings Reporter: Henry Robinson Assignee: Henry Robinson Attachments: ZOOKEEPER-627.patch, ZOOKEEPER-627.patch Reported on the list: I'm working on using ZooKeeper for an internal application at Digg. I've been using the zkpython package and I just noticed that the data I was receiving from a zookeeper.get() call was being truncated. After some quick digging I found that zookeeper.c limits the data returned to 512 characters (see http://svn.apache.org/viewvc/hadoop/zookeeper/tags/release-3.2.2/src/contrib/zkpython/src/c/zookeeper.c?view=markup line 855). Is there a reason for this? The only information regarding node size that I've read is that it should not exceed 1MB so this limit seems a bit arbitrary and restrictive. Thanks for the great work! Rich -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-627) zkpython arbitrarily restricts the size of a 'get' to 512 bytes
[ https://issues.apache.org/jira/browse/ZOOKEEPER-627?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henry Robinson updated ZOOKEEPER-627: - Status: Open (was: Patch Available) zkpython arbitrarily restricts the size of a 'get' to 512 bytes --- Key: ZOOKEEPER-627 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-627 Project: Zookeeper Issue Type: Bug Components: contrib-bindings Reporter: Henry Robinson Assignee: Henry Robinson Attachments: ZOOKEEPER-627.patch, ZOOKEEPER-627.patch Reported on the list: I'm working on using ZooKeeper for an internal application at Digg. I've been using the zkpython package and I just noticed that the data I was receiving from a zookeeper.get() call was being truncated. After some quick digging I found that zookeeper.c limits the data returned to 512 characters (see http://svn.apache.org/viewvc/hadoop/zookeeper/tags/release-3.2.2/src/contrib/zkpython/src/c/zookeeper.c?view=markup line 855). Is there a reason for this? The only information regarding node size that I've read is that it should not exceed 1MB so this limit seems a bit arbitrary and restrictive. Thanks for the great work! Rich -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-627) zkpython arbitrarily restricts the size of a 'get' to 512 bytes
[ https://issues.apache.org/jira/browse/ZOOKEEPER-627?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henry Robinson updated ZOOKEEPER-627: - Status: Patch Available (was: Open) zkpython arbitrarily restricts the size of a 'get' to 512 bytes --- Key: ZOOKEEPER-627 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-627 Project: Zookeeper Issue Type: Bug Components: contrib-bindings Reporter: Henry Robinson Assignee: Henry Robinson Attachments: ZOOKEEPER-627.patch, ZOOKEEPER-627.patch Reported on the list: I'm working on using ZooKeeper for an internal application at Digg. I've been using the zkpython package and I just noticed that the data I was receiving from a zookeeper.get() call was being truncated. After some quick digging I found that zookeeper.c limits the data returned to 512 characters (see http://svn.apache.org/viewvc/hadoop/zookeeper/tags/release-3.2.2/src/contrib/zkpython/src/c/zookeeper.c?view=markup line 855). Is there a reason for this? The only information regarding node size that I've read is that it should not exceed 1MB so this limit seems a bit arbitrary and restrictive. Thanks for the great work! Rich -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-627) zkpython arbitrarily restricts the size of a 'get' to 512 bytes
[ https://issues.apache.org/jira/browse/ZOOKEEPER-627?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12791432#action_12791432 ] Henry Robinson commented on ZOOKEEPER-627: -- This is what happens when you write a patch quickly :) Good catch, thanks! zkpython arbitrarily restricts the size of a 'get' to 512 bytes --- Key: ZOOKEEPER-627 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-627 Project: Zookeeper Issue Type: Bug Components: contrib-bindings Reporter: Henry Robinson Assignee: Henry Robinson Attachments: ZOOKEEPER-627.patch, ZOOKEEPER-627.patch Reported on the list: I'm working on using ZooKeeper for an internal application at Digg. I've been using the zkpython package and I just noticed that the data I was receiving from a zookeeper.get() call was being truncated. After some quick digging I found that zookeeper.c limits the data returned to 512 characters (see http://svn.apache.org/viewvc/hadoop/zookeeper/tags/release-3.2.2/src/contrib/zkpython/src/c/zookeeper.c?view=markup line 855). Is there a reason for this? The only information regarding node size that I've read is that it should not exceed 1MB so this limit seems a bit arbitrary and restrictive. Thanks for the great work! Rich -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: 3.3.0 release planning
March 10th sounds good to me. ben Patrick Hunt wrote: Now that the fix releases are out we should look at nailing down a date for 3.3.0, once we define a date we can triage the JIRA list and pare it down to what we think we can/should accomplish in the timeframe we have. December is mostly done given many ppl are out for holidays. I'm thinking March 10th to create a release candidate and put it up for the vote. This will give ppl 8weeks or so after the holidays to complete any blockers before I cut the rel candiate. This sound good? Patrick
Re: 3.3.0 release planning
+1 mahadev On 12/16/09 8:54 AM, Benjamin Reed br...@yahoo-inc.com wrote: March 10th sounds good to me. ben Patrick Hunt wrote: Now that the fix releases are out we should look at nailing down a date for 3.3.0, once we define a date we can triage the JIRA list and pare it down to what we think we can/should accomplish in the timeframe we have. December is mostly done given many ppl are out for holidays. I'm thinking March 10th to create a release candidate and put it up for the vote. This will give ppl 8weeks or so after the holidays to complete any blockers before I cut the rel candiate. This sound good? Patrick
[jira] Commented: (ZOOKEEPER-609) ObserverTest failure zk should not be connected expected not same
[ https://issues.apache.org/jira/browse/ZOOKEEPER-609?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12791476#action_12791476 ] Patrick Hunt commented on ZOOKEEPER-609: I re-ran the test with the provide patch and now see an NPE: Testcase: testObserver took 30.167 sec FAILED waiting for server 1 being up junit.framework.AssertionFailedError: waiting for server 1 being up at org.apache.zookeeper.server.quorum.ObserverTest.testObserver(ObserverTest.java:87) Testcase: testSingleObserver took 30.109 sec Caused an ERROR null java.lang.NullPointerException at org.apache.zookeeper.server.quorum.QuorumPeerMain.shutdown(QuorumPeerMain.java:147) at org.apache.zookeeper.server.quorum.QuorumPeerMainTest$TestQPMain.shutdown(QuorumPeerMainTest.java:62) at org.apache.zookeeper.server.quorum.QuorumPeerTestBase$MainThread.shutdown(QuorumPeerTestBase.java:97) at org.apache.zookeeper.server.quorum.ObserverTest.testSingleObserver(ObserverTest.java:189) Testcase: testLeaderElectionFail took 0.002 sec ObserverTest failure zk should not be connected expected not same --- Key: ZOOKEEPER-609 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-609 Project: Zookeeper Issue Type: Bug Components: quorum, server Affects Versions: 3.3.0 Reporter: Patrick Hunt Assignee: Henry Robinson Priority: Blocker Fix For: 3.3.0 Attachments: TEST-org.apache.zookeeper.server.quorum.ObserverTest.xml, ZOOKEEPER-609.patch ObserverTest failed running on 8core I ran the test as: ant -Dtest.junit.output.format=xml -Dtest.output -Dtestcase=AsyncHammerTest clean test-core-java test.out -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-609) ObserverTest failure zk should not be connected expected not same
[ https://issues.apache.org/jira/browse/ZOOKEEPER-609?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12791477#action_12791477 ] Patrick Hunt commented on ZOOKEEPER-609: Btw, failure was on jvm 1.6.0_17 as run by: ant -Dtestcase=ObserverTest clean test-core-java this is 8core linux (same as this: http://wiki.apache.org/hadoop/ZooKeeper/ServiceLatencyOverview#Hardware) ObserverTest failure zk should not be connected expected not same --- Key: ZOOKEEPER-609 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-609 Project: Zookeeper Issue Type: Bug Components: quorum, server Affects Versions: 3.3.0 Reporter: Patrick Hunt Assignee: Henry Robinson Priority: Blocker Fix For: 3.3.0 Attachments: TEST-org.apache.zookeeper.server.quorum.ObserverTest.xml, ZOOKEEPER-609.patch ObserverTest failed running on 8core I ran the test as: ant -Dtest.junit.output.format=xml -Dtest.output -Dtestcase=AsyncHammerTest clean test-core-java test.out -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-627) zkpython arbitrarily restricts the size of a 'get' to 512 bytes
[ https://issues.apache.org/jira/browse/ZOOKEEPER-627?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12791483#action_12791483 ] Hadoop QA commented on ZOOKEEPER-627: - -1 overall. Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12428181/ZOOKEEPER-627.patch against trunk revision 891034. +1 @author. The patch does not contain any @author tags. +1 tests included. The patch appears to include 3 new or modified tests. -1 patch. The patch command could not apply the patch. Console output: http://hudson.zones.apache.org/hudson/job/Zookeeper-Patch-h8.grid.sp2.yahoo.net/91/console This message is automatically generated. zkpython arbitrarily restricts the size of a 'get' to 512 bytes --- Key: ZOOKEEPER-627 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-627 Project: Zookeeper Issue Type: Bug Components: contrib-bindings Reporter: Henry Robinson Assignee: Henry Robinson Attachments: ZOOKEEPER-627.patch, ZOOKEEPER-627.patch Reported on the list: I'm working on using ZooKeeper for an internal application at Digg. I've been using the zkpython package and I just noticed that the data I was receiving from a zookeeper.get() call was being truncated. After some quick digging I found that zookeeper.c limits the data returned to 512 characters (see http://svn.apache.org/viewvc/hadoop/zookeeper/tags/release-3.2.2/src/contrib/zkpython/src/c/zookeeper.c?view=markup line 855). Is there a reason for this? The only information regarding node size that I've read is that it should not exceed 1MB so this limit seems a bit arbitrary and restrictive. Thanks for the great work! Rich -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-609) ObserverTest failure zk should not be connected expected not same
[ https://issues.apache.org/jira/browse/ZOOKEEPER-609?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12791485#action_12791485 ] Henry Robinson commented on ZOOKEEPER-609: -- Patrick - See https://issues.apache.org/jira/browse/ZOOKEEPER-630 - there are duplicate ObserverTest.java files in trunk. This failure is in one removed by that patch. Can you try applying 630, then this patch, then trying? Thanks, Henry ObserverTest failure zk should not be connected expected not same --- Key: ZOOKEEPER-609 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-609 Project: Zookeeper Issue Type: Bug Components: quorum, server Affects Versions: 3.3.0 Reporter: Patrick Hunt Assignee: Henry Robinson Priority: Blocker Fix For: 3.3.0 Attachments: TEST-org.apache.zookeeper.server.quorum.ObserverTest.xml, ZOOKEEPER-609.patch ObserverTest failed running on 8core I ran the test as: ant -Dtest.junit.output.format=xml -Dtest.output -Dtestcase=AsyncHammerTest clean test-core-java test.out -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-627) zkpython arbitrarily restricts the size of a 'get' to 512 bytes
[ https://issues.apache.org/jira/browse/ZOOKEEPER-627?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henry Robinson updated ZOOKEEPER-627: - Attachment: ZOOKEEPER-627.patch Re-submitting with --no-prefix, so hudson can apply the patch. zkpython arbitrarily restricts the size of a 'get' to 512 bytes --- Key: ZOOKEEPER-627 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-627 Project: Zookeeper Issue Type: Bug Components: contrib-bindings Reporter: Henry Robinson Assignee: Henry Robinson Attachments: ZOOKEEPER-627.patch, ZOOKEEPER-627.patch, ZOOKEEPER-627.patch Reported on the list: I'm working on using ZooKeeper for an internal application at Digg. I've been using the zkpython package and I just noticed that the data I was receiving from a zookeeper.get() call was being truncated. After some quick digging I found that zookeeper.c limits the data returned to 512 characters (see http://svn.apache.org/viewvc/hadoop/zookeeper/tags/release-3.2.2/src/contrib/zkpython/src/c/zookeeper.c?view=markup line 855). Is there a reason for this? The only information regarding node size that I've read is that it should not exceed 1MB so this limit seems a bit arbitrary and restrictive. Thanks for the great work! Rich -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-627) zkpython arbitrarily restricts the size of a 'get' to 512 bytes
[ https://issues.apache.org/jira/browse/ZOOKEEPER-627?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henry Robinson updated ZOOKEEPER-627: - Status: Open (was: Patch Available) zkpython arbitrarily restricts the size of a 'get' to 512 bytes --- Key: ZOOKEEPER-627 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-627 Project: Zookeeper Issue Type: Bug Components: contrib-bindings Reporter: Henry Robinson Assignee: Henry Robinson Attachments: ZOOKEEPER-627.patch, ZOOKEEPER-627.patch, ZOOKEEPER-627.patch Reported on the list: I'm working on using ZooKeeper for an internal application at Digg. I've been using the zkpython package and I just noticed that the data I was receiving from a zookeeper.get() call was being truncated. After some quick digging I found that zookeeper.c limits the data returned to 512 characters (see http://svn.apache.org/viewvc/hadoop/zookeeper/tags/release-3.2.2/src/contrib/zkpython/src/c/zookeeper.c?view=markup line 855). Is there a reason for this? The only information regarding node size that I've read is that it should not exceed 1MB so this limit seems a bit arbitrary and restrictive. Thanks for the great work! Rich -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-627) zkpython arbitrarily restricts the size of a 'get' to 512 bytes
[ https://issues.apache.org/jira/browse/ZOOKEEPER-627?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henry Robinson updated ZOOKEEPER-627: - Status: Patch Available (was: Open) zkpython arbitrarily restricts the size of a 'get' to 512 bytes --- Key: ZOOKEEPER-627 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-627 Project: Zookeeper Issue Type: Bug Components: contrib-bindings Reporter: Henry Robinson Assignee: Henry Robinson Attachments: ZOOKEEPER-627.patch, ZOOKEEPER-627.patch, ZOOKEEPER-627.patch Reported on the list: I'm working on using ZooKeeper for an internal application at Digg. I've been using the zkpython package and I just noticed that the data I was receiving from a zookeeper.get() call was being truncated. After some quick digging I found that zookeeper.c limits the data returned to 512 characters (see http://svn.apache.org/viewvc/hadoop/zookeeper/tags/release-3.2.2/src/contrib/zkpython/src/c/zookeeper.c?view=markup line 855). Is there a reason for this? The only information regarding node size that I've read is that it should not exceed 1MB so this limit seems a bit arbitrary and restrictive. Thanks for the great work! Rich -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-630) Trunk has duplicate ObserverTest.java files
[ https://issues.apache.org/jira/browse/ZOOKEEPER-630?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12791496#action_12791496 ] Patrick Hunt commented on ZOOKEEPER-630: When you say duplicate you mean that the other file contains the same set of tests? What I mean is, we aren't effectively removing tests as part of this patch, is that right? Trunk has duplicate ObserverTest.java files --- Key: ZOOKEEPER-630 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-630 Project: Zookeeper Issue Type: Bug Components: tests Reporter: Henry Robinson Assignee: Henry Robinson Attachments: ZOOKEEPER-630.patch There are two identical ObserverTest.java files in trunk. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-630) Trunk has duplicate ObserverTest.java files
[ https://issues.apache.org/jira/browse/ZOOKEEPER-630?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12791498#action_12791498 ] Henry Robinson commented on ZOOKEEPER-630: -- That's what I mean, yes. Same set of tests (although now slightly different since Flavio's patch updated the one I left in), no logical test removal. Trunk has duplicate ObserverTest.java files --- Key: ZOOKEEPER-630 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-630 Project: Zookeeper Issue Type: Bug Components: tests Reporter: Henry Robinson Assignee: Henry Robinson Attachments: ZOOKEEPER-630.patch There are two identical ObserverTest.java files in trunk. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-630) Trunk has duplicate ObserverTest.java files
[ https://issues.apache.org/jira/browse/ZOOKEEPER-630?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12791499#action_12791499 ] Henry Robinson commented on ZOOKEEPER-630: -- Except there's one test that should have been removed, which wasn't removed in the duplicate (the test to make sure that an exception is thrown if the wrong LE algorithm is used - this is no longer appropriate). So we are removing that test, but it should be removed anyhow. Trunk has duplicate ObserverTest.java files --- Key: ZOOKEEPER-630 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-630 Project: Zookeeper Issue Type: Bug Components: tests Reporter: Henry Robinson Assignee: Henry Robinson Attachments: ZOOKEEPER-630.patch There are two identical ObserverTest.java files in trunk. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-609) ObserverTest failure zk should not be connected expected not same
[ https://issues.apache.org/jira/browse/ZOOKEEPER-609?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Hunt updated ZOOKEEPER-609: --- Resolution: Fixed Hadoop Flags: [Reviewed] Status: Resolved (was: Patch Available) +1 with ZOOKEEPER-630 the tests now pass for me. Thanks Henry ObserverTest failure zk should not be connected expected not same --- Key: ZOOKEEPER-609 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-609 Project: Zookeeper Issue Type: Bug Components: quorum, server Affects Versions: 3.3.0 Reporter: Patrick Hunt Assignee: Henry Robinson Priority: Blocker Fix For: 3.3.0 Attachments: TEST-org.apache.zookeeper.server.quorum.ObserverTest.xml, ZOOKEEPER-609.patch ObserverTest failed running on 8core I ran the test as: ant -Dtest.junit.output.format=xml -Dtest.output -Dtestcase=AsyncHammerTest clean test-core-java test.out -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-630) Trunk has duplicate ObserverTest.java files
[ https://issues.apache.org/jira/browse/ZOOKEEPER-630?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Hunt updated ZOOKEEPER-630: --- Resolution: Fixed Fix Version/s: 3.3.0 Hadoop Flags: [Reviewed] Status: Resolved (was: Patch Available) +1 thanks Henry Trunk has duplicate ObserverTest.java files --- Key: ZOOKEEPER-630 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-630 Project: Zookeeper Issue Type: Bug Components: tests Reporter: Henry Robinson Assignee: Henry Robinson Fix For: 3.3.0 Attachments: ZOOKEEPER-630.patch There are two identical ObserverTest.java files in trunk. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: 3.3.0 release planning
Sounds good. Any more input sing out, for the time being I'll go with 3/10/2010 as the planned release date. I'm going to start triaging issues listed as fix for 3.3.0, pushing some things that are not critical/blocker/assigned into 3.4.0 or unscheduled. This doesn't mean people can't work on these issues, just that they are not planned for the release - it's really for planning purposes while the JIRA is open. If people come up with a patch for something feel free to submit it for 3.3.0 regardless of the current fix date listed in the JIRA. If you feel something should/must be in 3.3.0 feel free to comment on jira or message the list - obv backing that up with a patch increases the chances. ;-) If you have JIRAs assigned to you that are open and you don't plan to work on the JIRA it would probably be a good idea to update it to unassigned instead. Again, helps in planning and understanding the workload. Once I do the initial triage I'll message the list again with some release status type information, esp as we get closer to the release date. If you want to work on a JIRA that's risky it's obv better to work on it now than wait until the release date comes near. Regards, Patrick Mahadev Konar wrote: +1 mahadev On 12/16/09 8:54 AM, Benjamin Reed br...@yahoo-inc.com wrote: March 10th sounds good to me. ben Patrick Hunt wrote: Now that the fix releases are out we should look at nailing down a date for 3.3.0, once we define a date we can triage the JIRA list and pare it down to what we think we can/should accomplish in the timeframe we have. December is mostly done given many ppl are out for holidays. I'm thinking March 10th to create a release candidate and put it up for the vote. This will give ppl 8weeks or so after the holidays to complete any blockers before I cut the rel candiate. This sound good? Patrick
[jira] Commented: (ZOOKEEPER-629) FLELostMessageTest assumes that the first zxid on a startup of quorum is -1.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-629?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12791531#action_12791531 ] Mahadev konar commented on ZOOKEEPER-629: - the -1 is because this patch is dependent on ZOOKEEPER-596 to get in. I will include this patch with ZOOKEEPER-596. thanks flavio. FLELostMessageTest assumes that the first zxid on a startup of quorum is -1. Key: ZOOKEEPER-629 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-629 Project: Zookeeper Issue Type: Bug Reporter: Mahadev konar Assignee: Flavio Paiva Junqueira Fix For: 3.3.0 Attachments: ZOOKEEPER-629.patch FLELostMessageTest assumes that the first zxid exchange will be -1 zxid. WIth ZOOKEEPER-596 the zxid would be 0 and not -1. So the corresponding change needs to be made to this test. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-628) the ephemeral node wouldn't disapper due to session close error
[ https://issues.apache.org/jira/browse/ZOOKEEPER-628?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12791537#action_12791537 ] Patrick Hunt commented on ZOOKEEPER-628: Qian this is great information. Can you tar/gzip the log files from all the servers and attach them? Any/all log files you have would be useful for us to see. the ephemeral node wouldn't disapper due to session close error --- Key: ZOOKEEPER-628 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-628 Project: Zookeeper Issue Type: Bug Components: server Affects Versions: 3.2.1 Environment: Linux 2.6.9 x86_64 Reporter: Qian Ye I find a very strange scenario today, I'm not sure how it happen, I just found it like this. Maybe you can give me some information about it, my Zookeeper Server is version 3.2.1. My Zookeeper cluster contains three servers, with ip: 10.81.12.144,10.81.12.145,10.81.12.141. I wrote a client to create ephemeral node under znode: se/diserver_tc. The client runs on the server with ip 10.81.13.173. The client can create a ephemeral node on zookeeper server and write the host ip (10.81.13.173) in to the node as its data. There is only one client process can be running at a time, because the client will listen to a certain port. It is strange that I found there were two ephemeral node with the ip 10.81.13.173 under znode se/diserver_tc. se/diserver_tc/diserver_tc67 STAT: czxid: 124554079820 mzxid: 124554079820 ctime: 1260609598547 mtime: 1260609598547 version: 0 cversion: 0 aversion: 0 ephemeralOwner: 226627854640480810 dataLength: 92 numChildren: 0 pzxid: 124554079820 se/diserver_tc/diserver_tc95 STAT: czxid: 128849019107 mzxid: 128849019107 ctime: 1260772197356 mtime: 1260772197356 version: 0 cversion: 0 aversion: 0 ephemeralOwner: 154673159808876591 dataLength: 92 numChildren: 0 pzxid: 128849019107 There are TWO with different session id! And after I kill the client process on the server 10.81.13.173, the se/diserver_tc/diserver_tc95 node disappear, but the se/diserver_tc/diserver_tc67 stay the same. That means it is not my coding mistake to create the node twice. I checked several times and I'm sure that there is no another client instance running. And I use the 'stat' command to check the three zookeeper servers, and there is no client from 10.81.13.173, $echo stat | nc 10.81.12.144 2181 Zookeeper version: 3.2.1-808558, built on 08/27/2009 18:48 GMT Clients: /10.81.13.173:35676[1](queued=0,recved=0,sent=0) # it is caused by the nc process Latency min/avg/max: 0/3/254 Received: 11081 Sent: 0 Outstanding: 0 Zxid: 0x1e01f5 Mode: follower Node count: 32 $ echo stat | nc 10.81.12.141 2181 Zookeeper version: 3.2.1-808558, built on 08/27/2009 18:48 GMT Clients: /10.81.12.152:58110[1](queued=0,recved=10374,sent=0) /10.81.13.173:35677[1](queued=0,recved=0,sent=0) # it is caused by the nc process Latency min/avg/max: 0/0/37 Received: 37128 Sent: 0 Outstanding: 0 Zxid: 0x1e01f5 Mode: follower Node count: 26 $ echo stat | nc 10.81.12.145 2181 Zookeeper version: 3.2.1-808558, built on 08/27/2009 18:48 GMT Clients: /10.81.12.153:19130[1](queued=0,recved=10624,sent=0) /10.81.13.173:35678[1](queued=0,recved=0,sent=0) # it is caused by the nc process Latency min/avg/max: 0/2/213 Received: 26700 Sent: 0 Outstanding: 0 Zxid: 0x1e01f5 Mode: leader Node count: 26 The three 'stat' commands show different Node count! -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: A very strange scenario, may due to some bug on the server side
Hi Qian, You can just upload the server logs to this jira and we can figure out if there is something useful that we can use to find out what happened. Thanks mahadev On 12/15/09 6:05 PM, Qian Ye yeqian@gmail.com wrote: I have opened a jira for the issue: https://issues.apache.org/jira/browse/ZOOKEEPER-628 and my zookeeper version is 3.2.1, the se/diserver_tc/diserver_ tc67 only appear on the server 10.81.12.144. I will attach the additional information to the jira. thx On Wed, Dec 16, 2009 at 1:57 AM, Patrick Hunt ph...@apache.org wrote: You might also try the dump command for all 3 servers (similar to the stat command - it's a 4letterword) and look at it's output -- it includes information on ephemeral nodes. Patrick Qian Ye wrote: Hi guys: I find a very strange scenario today, I'm not sure how it happen, I just found it like this. Maybe you can give me some information about it, my Zookeeper Server is version 3.2.1. My Zookeeper cluster contains three servers, with ip: 10.81.12.144,10.81.12.145,10.81.12.141. I wrote a client to create ephemeral node under znode: *se/diserver_tc*. The client runs on the server with ip 10.81.13.173. The client can create a ephemeral node on zookeeper server and write the host ip (10.81.13.173) in to the node as its data. There is only one client process can be running at a time, because the client will listen to a certain port. It is strange that I found there were two ephemeral node with the ip 10.81.13.173 under znode se/diserver_tc. *se/diserver_tc/diserver_tc67* STAT: czxid: 124554079820 mzxid: 124554079820 ctime: 1260609598547 mtime: 1260609598547 version: 0 cversion: 0 aversion: 0 ephemeralOwner: 226627854640480810 dataLength: 92 numChildren: 0 pzxid: 124554079820 *se/diserver_tc/diserver_tc95 *STAT: czxid: 128849019107 mzxid: 128849019107 ctime: 1260772197356 mtime: 1260772197356 version: 0 cversion: 0 aversion: 0 ephemeralOwner: 154673159808876591 dataLength: 92 numChildren: 0 pzxid: 128849019107* * There are TWO with different session id! And after I kill the client process on the server 10.81.13.173, the *se/diserver_tc/diserver_tc95 *node disappear, but the *se/diserver_tc/diserver_tc67 *stay the same. That means it is not my coding mistake to create the node twice. I checked several times and I'm sure that there is no another client instance running. And I use the 'stat' command to check the three zookeeper servers, and there is no client from 10.81.13.173, $echo stat | nc 10.81.12.144 2181 Zookeeper version: 3.2.1-808558, built on 08/27/2009 18:48 GMT Clients: /10.81.13.173:35676[1](queued=0,recved=0,sent=0) *# it is caused by the nc process* Latency min/avg/max: 0/3/254 Received: 11081 Sent: 0 Outstanding: 0 Zxid: 0x1e01f5 Mode: follower *Node count: 32 * $ echo stat | nc 10.81.12.141 2181 Zookeeper version: 3.2.1-808558, built on 08/27/2009 18:48 GMT Clients: /10.81.12.152:58110[1](queued=0,recved=10374,sent=0) /10.81.13.173:35677[1](queued=0,recved=0,sent=0) *# it is caused by the nc process* Latency min/avg/max: 0/0/37 Received: 37128 Sent: 0 Outstanding: 0 Zxid: 0x1e01f5 Mode: follower *Node count: 26* $ echo stat | nc 10.81.12.145 2181 Zookeeper version: 3.2.1-808558, built on 08/27/2009 18:48 GMT Clients: /10.81.12.153:19130[1](queued=0,recved=10624,sent=0) /10.81.13.173:35678[1](queued=0,recved=0,sent=0) *# it is caused by the nc process* Latency min/avg/max: 0/2/213 Received: 26700 Sent: 0 Outstanding: 0 Zxid: 0x1e01f5 Mode: leader *Node count: 26* The three 'stat' commands show different Node count! Just cannot understand how it happened, can anyone give me some explanation about it?
[jira] Updated: (ZOOKEEPER-596) The last logged zxid calculated by zookeeper servers could cause problems in leader election if data gets corrupted.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-596?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mahadev konar updated ZOOKEEPER-596: Status: Open (was: Patch Available) The last logged zxid calculated by zookeeper servers could cause problems in leader election if data gets corrupted. Key: ZOOKEEPER-596 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-596 Project: Zookeeper Issue Type: Bug Affects Versions: 3.2.1 Reporter: Mahadev konar Assignee: Mahadev konar Fix For: 3.3.0 Attachments: ZOOKEEPER-596.patch, ZOOKEEPER-596.patch, ZOOKEEPER-596.patch, ZOOKEEPER-596.patch It is possible that the last loggged zxid as reported by all the servers during leader election is not the last zxid that the server can upload data to. It is very much possible that some transaction or snapshot gets corrupted and the servers actually do not have valid data till last logged zxid. We need to make sure that what the servers report as there last logged zxid, they are able to load data till that zxid. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-596) The last logged zxid calculated by zookeeper servers could cause problems in leader election if data gets corrupted.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-596?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mahadev konar updated ZOOKEEPER-596: Attachment: ZOOKEEPER-596.patch looks like the patch got stale uploading a new patch that applies to the trunk. The last logged zxid calculated by zookeeper servers could cause problems in leader election if data gets corrupted. Key: ZOOKEEPER-596 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-596 Project: Zookeeper Issue Type: Bug Affects Versions: 3.2.1 Reporter: Mahadev konar Assignee: Mahadev konar Fix For: 3.3.0 Attachments: ZOOKEEPER-596.patch, ZOOKEEPER-596.patch, ZOOKEEPER-596.patch, ZOOKEEPER-596.patch It is possible that the last loggged zxid as reported by all the servers during leader election is not the last zxid that the server can upload data to. It is very much possible that some transaction or snapshot gets corrupted and the servers actually do not have valid data till last logged zxid. We need to make sure that what the servers report as there last logged zxid, they are able to load data till that zxid. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-596) The last logged zxid calculated by zookeeper servers could cause problems in leader election if data gets corrupted.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-596?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mahadev konar updated ZOOKEEPER-596: Status: Patch Available (was: Open) The last logged zxid calculated by zookeeper servers could cause problems in leader election if data gets corrupted. Key: ZOOKEEPER-596 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-596 Project: Zookeeper Issue Type: Bug Affects Versions: 3.2.1 Reporter: Mahadev konar Assignee: Mahadev konar Fix For: 3.3.0 Attachments: ZOOKEEPER-596.patch, ZOOKEEPER-596.patch, ZOOKEEPER-596.patch, ZOOKEEPER-596.patch It is possible that the last loggged zxid as reported by all the servers during leader election is not the last zxid that the server can upload data to. It is very much possible that some transaction or snapshot gets corrupted and the servers actually do not have valid data till last logged zxid. We need to make sure that what the servers report as there last logged zxid, they are able to load data till that zxid. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-596) The last logged zxid calculated by zookeeper servers could cause problems in leader election if data gets corrupted.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-596?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12791566#action_12791566 ] Hadoop QA commented on ZOOKEEPER-596: - +1 overall. Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12428212/ZOOKEEPER-596.patch against trunk revision 891368. +1 @author. The patch does not contain any @author tags. +1 tests included. The patch appears to include 9 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-h7.grid.sp2.yahoo.net/29/testReport/ Findbugs warnings: http://hudson.zones.apache.org/hudson/job/Zookeeper-Patch-h7.grid.sp2.yahoo.net/29/artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html Console output: http://hudson.zones.apache.org/hudson/job/Zookeeper-Patch-h7.grid.sp2.yahoo.net/29/console This message is automatically generated. The last logged zxid calculated by zookeeper servers could cause problems in leader election if data gets corrupted. Key: ZOOKEEPER-596 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-596 Project: Zookeeper Issue Type: Bug Affects Versions: 3.2.1 Reporter: Mahadev konar Assignee: Mahadev konar Fix For: 3.3.0 Attachments: ZOOKEEPER-596.patch, ZOOKEEPER-596.patch, ZOOKEEPER-596.patch, ZOOKEEPER-596.patch It is possible that the last loggged zxid as reported by all the servers during leader election is not the last zxid that the server can upload data to. It is very much possible that some transaction or snapshot gets corrupted and the servers actually do not have valid data till last logged zxid. We need to make sure that what the servers report as there last logged zxid, they are able to load data till that zxid. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-628) the ephemeral node wouldn't disapper due to session close error
[ https://issues.apache.org/jira/browse/ZOOKEEPER-628?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12791583#action_12791583 ] Mahadev konar commented on ZOOKEEPER-628: - qian, I was thinking about how this could happen and I think this could be possible with some amount of corruption in the zk database. ZOOKEEPER-596 should get rid of all those scenarios. Would it be possible for you to upload the zookeeper data directory and snapshots for all the servers? It would come in very handy to find out what the problem could have been. you can tar and zip it up and upload it on the jira. the ephemeral node wouldn't disapper due to session close error --- Key: ZOOKEEPER-628 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-628 Project: Zookeeper Issue Type: Bug Components: server Affects Versions: 3.2.1 Environment: Linux 2.6.9 x86_64 Reporter: Qian Ye I find a very strange scenario today, I'm not sure how it happen, I just found it like this. Maybe you can give me some information about it, my Zookeeper Server is version 3.2.1. My Zookeeper cluster contains three servers, with ip: 10.81.12.144,10.81.12.145,10.81.12.141. I wrote a client to create ephemeral node under znode: se/diserver_tc. The client runs on the server with ip 10.81.13.173. The client can create a ephemeral node on zookeeper server and write the host ip (10.81.13.173) in to the node as its data. There is only one client process can be running at a time, because the client will listen to a certain port. It is strange that I found there were two ephemeral node with the ip 10.81.13.173 under znode se/diserver_tc. se/diserver_tc/diserver_tc67 STAT: czxid: 124554079820 mzxid: 124554079820 ctime: 1260609598547 mtime: 1260609598547 version: 0 cversion: 0 aversion: 0 ephemeralOwner: 226627854640480810 dataLength: 92 numChildren: 0 pzxid: 124554079820 se/diserver_tc/diserver_tc95 STAT: czxid: 128849019107 mzxid: 128849019107 ctime: 1260772197356 mtime: 1260772197356 version: 0 cversion: 0 aversion: 0 ephemeralOwner: 154673159808876591 dataLength: 92 numChildren: 0 pzxid: 128849019107 There are TWO with different session id! And after I kill the client process on the server 10.81.13.173, the se/diserver_tc/diserver_tc95 node disappear, but the se/diserver_tc/diserver_tc67 stay the same. That means it is not my coding mistake to create the node twice. I checked several times and I'm sure that there is no another client instance running. And I use the 'stat' command to check the three zookeeper servers, and there is no client from 10.81.13.173, $echo stat | nc 10.81.12.144 2181 Zookeeper version: 3.2.1-808558, built on 08/27/2009 18:48 GMT Clients: /10.81.13.173:35676[1](queued=0,recved=0,sent=0) # it is caused by the nc process Latency min/avg/max: 0/3/254 Received: 11081 Sent: 0 Outstanding: 0 Zxid: 0x1e01f5 Mode: follower Node count: 32 $ echo stat | nc 10.81.12.141 2181 Zookeeper version: 3.2.1-808558, built on 08/27/2009 18:48 GMT Clients: /10.81.12.152:58110[1](queued=0,recved=10374,sent=0) /10.81.13.173:35677[1](queued=0,recved=0,sent=0) # it is caused by the nc process Latency min/avg/max: 0/0/37 Received: 37128 Sent: 0 Outstanding: 0 Zxid: 0x1e01f5 Mode: follower Node count: 26 $ echo stat | nc 10.81.12.145 2181 Zookeeper version: 3.2.1-808558, built on 08/27/2009 18:48 GMT Clients: /10.81.12.153:19130[1](queued=0,recved=10624,sent=0) /10.81.13.173:35678[1](queued=0,recved=0,sent=0) # it is caused by the nc process Latency min/avg/max: 0/2/213 Received: 26700 Sent: 0 Outstanding: 0 Zxid: 0x1e01f5 Mode: leader Node count: 26 The three 'stat' commands show different Node count! -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-596) The last logged zxid calculated by zookeeper servers could cause problems in leader election if data gets corrupted.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-596?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mahadev konar updated ZOOKEEPER-596: Status: Open (was: Patch Available) The last logged zxid calculated by zookeeper servers could cause problems in leader election if data gets corrupted. Key: ZOOKEEPER-596 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-596 Project: Zookeeper Issue Type: Bug Affects Versions: 3.2.1 Reporter: Mahadev konar Assignee: Mahadev konar Fix For: 3.3.0 Attachments: ZOOKEEPER-596.patch, ZOOKEEPER-596.patch, ZOOKEEPER-596.patch, ZOOKEEPER-596.patch It is possible that the last loggged zxid as reported by all the servers during leader election is not the last zxid that the server can upload data to. It is very much possible that some transaction or snapshot gets corrupted and the servers actually do not have valid data till last logged zxid. We need to make sure that what the servers report as there last logged zxid, they are able to load data till that zxid. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-596) The last logged zxid calculated by zookeeper servers could cause problems in leader election if data gets corrupted.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-596?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mahadev konar updated ZOOKEEPER-596: Attachment: ZOOKEEPER-596.patch an updated patch with acess methods for accessing zkdatabase from zookeeperserver. It was accessing members directly which I think is a bad idea. The last logged zxid calculated by zookeeper servers could cause problems in leader election if data gets corrupted. Key: ZOOKEEPER-596 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-596 Project: Zookeeper Issue Type: Bug Affects Versions: 3.2.1 Reporter: Mahadev konar Assignee: Mahadev konar Fix For: 3.3.0 Attachments: ZOOKEEPER-596.patch, ZOOKEEPER-596.patch, ZOOKEEPER-596.patch, ZOOKEEPER-596.patch, ZOOKEEPER-596.patch It is possible that the last loggged zxid as reported by all the servers during leader election is not the last zxid that the server can upload data to. It is very much possible that some transaction or snapshot gets corrupted and the servers actually do not have valid data till last logged zxid. We need to make sure that what the servers report as there last logged zxid, they are able to load data till that zxid. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-596) The last logged zxid calculated by zookeeper servers could cause problems in leader election if data gets corrupted.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-596?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mahadev konar updated ZOOKEEPER-596: Status: Patch Available (was: Open) The last logged zxid calculated by zookeeper servers could cause problems in leader election if data gets corrupted. Key: ZOOKEEPER-596 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-596 Project: Zookeeper Issue Type: Bug Affects Versions: 3.2.1 Reporter: Mahadev konar Assignee: Mahadev konar Fix For: 3.3.0 Attachments: ZOOKEEPER-596.patch, ZOOKEEPER-596.patch, ZOOKEEPER-596.patch, ZOOKEEPER-596.patch, ZOOKEEPER-596.patch It is possible that the last loggged zxid as reported by all the servers during leader election is not the last zxid that the server can upload data to. It is very much possible that some transaction or snapshot gets corrupted and the servers actually do not have valid data till last logged zxid. We need to make sure that what the servers report as there last logged zxid, they are able to load data till that zxid. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-596) The last logged zxid calculated by zookeeper servers could cause problems in leader election if data gets corrupted.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-596?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12791611#action_12791611 ] Hadoop QA commented on ZOOKEEPER-596: - +1 overall. Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12428223/ZOOKEEPER-596.patch against trunk revision 891368. +1 @author. The patch does not contain any @author tags. +1 tests included. The patch appears to include 9 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-h7.grid.sp2.yahoo.net/30/testReport/ Findbugs warnings: http://hudson.zones.apache.org/hudson/job/Zookeeper-Patch-h7.grid.sp2.yahoo.net/30/artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html Console output: http://hudson.zones.apache.org/hudson/job/Zookeeper-Patch-h7.grid.sp2.yahoo.net/30/console This message is automatically generated. The last logged zxid calculated by zookeeper servers could cause problems in leader election if data gets corrupted. Key: ZOOKEEPER-596 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-596 Project: Zookeeper Issue Type: Bug Affects Versions: 3.2.1 Reporter: Mahadev konar Assignee: Mahadev konar Fix For: 3.3.0 Attachments: ZOOKEEPER-596.patch, ZOOKEEPER-596.patch, ZOOKEEPER-596.patch, ZOOKEEPER-596.patch, ZOOKEEPER-596.patch It is possible that the last loggged zxid as reported by all the servers during leader election is not the last zxid that the server can upload data to. It is very much possible that some transaction or snapshot gets corrupted and the servers actually do not have valid data till last logged zxid. We need to make sure that what the servers report as there last logged zxid, they are able to load data till that zxid. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-486) Improve bookie performance for large number of ledgers
[ https://issues.apache.org/jira/browse/ZOOKEEPER-486?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Reed updated ZOOKEEPER-486: Attachment: ZOOKEEPER-486.patch added the missing files. Improve bookie performance for large number of ledgers -- Key: ZOOKEEPER-486 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-486 Project: Zookeeper Issue Type: Improvement Components: contrib-bookkeeper Reporter: Flavio Paiva Junqueira Assignee: Benjamin Reed Attachments: ZOOKEEPER-486.patch, ZOOKEEPER-486.patch, ZOOKEEPER-486.patch, ZOOKEEPER-486.patch If we write simultaneously to a large number of ledgers on a bookie, then performance drops significantly due to more seeks on the ledger device. In such cases, we should be clustering ledgers into files to reduce the number of seeks, and performing sequential writes on each file. Clustering ledgers will impact read performance, so we would to have a knob to control such a feature. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-627) zkpython arbitrarily restricts the size of a 'get' to 512 bytes
[ https://issues.apache.org/jira/browse/ZOOKEEPER-627?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12791639#action_12791639 ] Hadoop QA commented on ZOOKEEPER-627: - +1 overall. Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12428198/ZOOKEEPER-627.patch against trunk revision 891368. +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-h8.grid.sp2.yahoo.net/92/testReport/ Findbugs warnings: http://hudson.zones.apache.org/hudson/job/Zookeeper-Patch-h8.grid.sp2.yahoo.net/92/artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html Console output: http://hudson.zones.apache.org/hudson/job/Zookeeper-Patch-h8.grid.sp2.yahoo.net/92/console This message is automatically generated. zkpython arbitrarily restricts the size of a 'get' to 512 bytes --- Key: ZOOKEEPER-627 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-627 Project: Zookeeper Issue Type: Bug Components: contrib-bindings Reporter: Henry Robinson Assignee: Henry Robinson Attachments: ZOOKEEPER-627.patch, ZOOKEEPER-627.patch, ZOOKEEPER-627.patch Reported on the list: I'm working on using ZooKeeper for an internal application at Digg. I've been using the zkpython package and I just noticed that the data I was receiving from a zookeeper.get() call was being truncated. After some quick digging I found that zookeeper.c limits the data returned to 512 characters (see http://svn.apache.org/viewvc/hadoop/zookeeper/tags/release-3.2.2/src/contrib/zkpython/src/c/zookeeper.c?view=markup line 855). Is there a reason for this? The only information regarding node size that I've read is that it should not exceed 1MB so this limit seems a bit arbitrary and restrictive. Thanks for the great work! Rich -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-486) Improve bookie performance for large number of ledgers
[ https://issues.apache.org/jira/browse/ZOOKEEPER-486?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Reed updated ZOOKEEPER-486: Attachment: ZOOKEEPER-486.patch the patch was rooted in bookkeeper rather than the top. Improve bookie performance for large number of ledgers -- Key: ZOOKEEPER-486 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-486 Project: Zookeeper Issue Type: Improvement Components: contrib-bookkeeper Reporter: Flavio Paiva Junqueira Assignee: Benjamin Reed Attachments: ZOOKEEPER-486.patch, ZOOKEEPER-486.patch, ZOOKEEPER-486.patch, ZOOKEEPER-486.patch, ZOOKEEPER-486.patch If we write simultaneously to a large number of ledgers on a bookie, then performance drops significantly due to more seeks on the ledger device. In such cases, we should be clustering ledgers into files to reduce the number of seeks, and performing sequential writes on each file. Clustering ledgers will impact read performance, so we would to have a knob to control such a feature. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-627) zkpython arbitrarily restricts the size of a 'get' to 512 bytes
[ https://issues.apache.org/jira/browse/ZOOKEEPER-627?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12791658#action_12791658 ] Mahadev konar commented on ZOOKEEPER-627: - +1 the patch looks good. btw, henry I just noticed that the c code in zookeeper.c has inconsistent formatting. Usually we use 4 space indentation with no tabs (which I like as well :))... do we want to fix that sometime (in a different patch obviously) or you want ot keep it as it is? zkpython arbitrarily restricts the size of a 'get' to 512 bytes --- Key: ZOOKEEPER-627 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-627 Project: Zookeeper Issue Type: Bug Components: contrib-bindings Reporter: Henry Robinson Assignee: Henry Robinson Attachments: ZOOKEEPER-627.patch, ZOOKEEPER-627.patch, ZOOKEEPER-627.patch Reported on the list: I'm working on using ZooKeeper for an internal application at Digg. I've been using the zkpython package and I just noticed that the data I was receiving from a zookeeper.get() call was being truncated. After some quick digging I found that zookeeper.c limits the data returned to 512 characters (see http://svn.apache.org/viewvc/hadoop/zookeeper/tags/release-3.2.2/src/contrib/zkpython/src/c/zookeeper.c?view=markup line 855). Is there a reason for this? The only information regarding node size that I've read is that it should not exceed 1MB so this limit seems a bit arbitrary and restrictive. Thanks for the great work! Rich -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-627) zkpython arbitrarily restricts the size of a 'get' to 512 bytes
[ https://issues.apache.org/jira/browse/ZOOKEEPER-627?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12791664#action_12791664 ] Henry Robinson commented on ZOOKEEPER-627: -- Yes, it needs a good spring clean - both to address the memory allocation issues that Gustavo has highlighted, and the style / spacing. I'll open the JIRA. zkpython arbitrarily restricts the size of a 'get' to 512 bytes --- Key: ZOOKEEPER-627 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-627 Project: Zookeeper Issue Type: Bug Components: contrib-bindings Reporter: Henry Robinson Assignee: Henry Robinson Attachments: ZOOKEEPER-627.patch, ZOOKEEPER-627.patch, ZOOKEEPER-627.patch Reported on the list: I'm working on using ZooKeeper for an internal application at Digg. I've been using the zkpython package and I just noticed that the data I was receiving from a zookeeper.get() call was being truncated. After some quick digging I found that zookeeper.c limits the data returned to 512 characters (see http://svn.apache.org/viewvc/hadoop/zookeeper/tags/release-3.2.2/src/contrib/zkpython/src/c/zookeeper.c?view=markup line 855). Is there a reason for this? The only information regarding node size that I've read is that it should not exceed 1MB so this limit seems a bit arbitrary and restrictive. Thanks for the great work! Rich -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-627) zkpython arbitrarily restricts the size of a 'get' to 512 bytes
[ https://issues.apache.org/jira/browse/ZOOKEEPER-627?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12791662#action_12791662 ] Gustavo Niemeyer commented on ZOOKEEPER-627: I vote for fixing it at some point. It'd be nice to fix the style as well (parenthesis, etc), in addition to the spacing. zkpython arbitrarily restricts the size of a 'get' to 512 bytes --- Key: ZOOKEEPER-627 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-627 Project: Zookeeper Issue Type: Bug Components: contrib-bindings Reporter: Henry Robinson Assignee: Henry Robinson Attachments: ZOOKEEPER-627.patch, ZOOKEEPER-627.patch, ZOOKEEPER-627.patch Reported on the list: I'm working on using ZooKeeper for an internal application at Digg. I've been using the zkpython package and I just noticed that the data I was receiving from a zookeeper.get() call was being truncated. After some quick digging I found that zookeeper.c limits the data returned to 512 characters (see http://svn.apache.org/viewvc/hadoop/zookeeper/tags/release-3.2.2/src/contrib/zkpython/src/c/zookeeper.c?view=markup line 855). Is there a reason for this? The only information regarding node size that I've read is that it should not exceed 1MB so this limit seems a bit arbitrary and restrictive. Thanks for the great work! Rich -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (ZOOKEEPER-631) zkpython's C code could do with a style clean-up
zkpython's C code could do with a style clean-up Key: ZOOKEEPER-631 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-631 Project: Zookeeper Issue Type: Improvement Components: contrib-bindings Reporter: Henry Robinson Assignee: Henry Robinson Priority: Minor Inconsistent formatting / use of parenthesis / some error checking - all need fixing. Also, the documentation in the header file could do with a reformat. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-627) zkpython arbitrarily restricts the size of a 'get' to 512 bytes
[ https://issues.apache.org/jira/browse/ZOOKEEPER-627?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12791666#action_12791666 ] Mahadev konar commented on ZOOKEEPER-627: - great ... ill go ahead and commit this patch for now. The new jira will take care of cleaning it up. zkpython arbitrarily restricts the size of a 'get' to 512 bytes --- Key: ZOOKEEPER-627 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-627 Project: Zookeeper Issue Type: Bug Components: contrib-bindings Reporter: Henry Robinson Assignee: Henry Robinson Attachments: ZOOKEEPER-627.patch, ZOOKEEPER-627.patch, ZOOKEEPER-627.patch Reported on the list: I'm working on using ZooKeeper for an internal application at Digg. I've been using the zkpython package and I just noticed that the data I was receiving from a zookeeper.get() call was being truncated. After some quick digging I found that zookeeper.c limits the data returned to 512 characters (see http://svn.apache.org/viewvc/hadoop/zookeeper/tags/release-3.2.2/src/contrib/zkpython/src/c/zookeeper.c?view=markup line 855). Is there a reason for this? The only information regarding node size that I've read is that it should not exceed 1MB so this limit seems a bit arbitrary and restrictive. Thanks for the great work! Rich -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-627) zkpython arbitrarily restricts the size of a 'get' to 512 bytes
[ https://issues.apache.org/jira/browse/ZOOKEEPER-627?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mahadev konar updated ZOOKEEPER-627: Fix Version/s: 3.3.0 zkpython arbitrarily restricts the size of a 'get' to 512 bytes --- Key: ZOOKEEPER-627 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-627 Project: Zookeeper Issue Type: Bug Components: contrib-bindings Reporter: Henry Robinson Assignee: Henry Robinson Fix For: 3.3.0 Attachments: ZOOKEEPER-627.patch, ZOOKEEPER-627.patch, ZOOKEEPER-627.patch Reported on the list: I'm working on using ZooKeeper for an internal application at Digg. I've been using the zkpython package and I just noticed that the data I was receiving from a zookeeper.get() call was being truncated. After some quick digging I found that zookeeper.c limits the data returned to 512 characters (see http://svn.apache.org/viewvc/hadoop/zookeeper/tags/release-3.2.2/src/contrib/zkpython/src/c/zookeeper.c?view=markup line 855). Is there a reason for this? The only information regarding node size that I've read is that it should not exceed 1MB so this limit seems a bit arbitrary and restrictive. Thanks for the great work! Rich -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-627) zkpython arbitrarily restricts the size of a 'get' to 512 bytes
[ https://issues.apache.org/jira/browse/ZOOKEEPER-627?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mahadev konar updated ZOOKEEPER-627: Resolution: Fixed Release Note: fix to remove restrictions on get in the zkpython library. Hadoop Flags: [Reviewed] Status: Resolved (was: Patch Available) I just committed this. thanks henry. zkpython arbitrarily restricts the size of a 'get' to 512 bytes --- Key: ZOOKEEPER-627 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-627 Project: Zookeeper Issue Type: Bug Components: contrib-bindings Reporter: Henry Robinson Assignee: Henry Robinson Attachments: ZOOKEEPER-627.patch, ZOOKEEPER-627.patch, ZOOKEEPER-627.patch Reported on the list: I'm working on using ZooKeeper for an internal application at Digg. I've been using the zkpython package and I just noticed that the data I was receiving from a zookeeper.get() call was being truncated. After some quick digging I found that zookeeper.c limits the data returned to 512 characters (see http://svn.apache.org/viewvc/hadoop/zookeeper/tags/release-3.2.2/src/contrib/zkpython/src/c/zookeeper.c?view=markup line 855). Is there a reason for this? The only information regarding node size that I've read is that it should not exceed 1MB so this limit seems a bit arbitrary and restrictive. Thanks for the great work! Rich -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-623) ClientBase in bookkeeper.util requires junit
[ https://issues.apache.org/jira/browse/ZOOKEEPER-623?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mahadev konar updated ZOOKEEPER-623: Fix Version/s: 3.3.0 flavio, Is this ClientBase file the same as in top level src/java/test? If yes, why are we not using that instead of copying it over to bookkeeper directory? We can just add a dependency on ant compile-test to be run from top level before you can run the ant test in bookkeeper and add build/test/classes to the classpath? no? ClientBase in bookkeeper.util requires junit Key: ZOOKEEPER-623 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-623 Project: Zookeeper Issue Type: Bug Components: contrib-bookkeeper Reporter: Flavio Paiva Junqueira Assignee: Flavio Paiva Junqueira Fix For: 3.3.0 Attachments: ZOOKEEPER-623.patch Class org.apache.bookkeeper.util.ClientBase requires junit, and when I tried to just compile bookkeeper, no test, with the patch of ZOOKEEPER-534, compilation failed. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-600) TODO pondering about allocation behavior in zkpython may be removed
[
https://issues.apache.org/jira/browse/ZOOKEEPER-600?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12791681#action_12791681
]
Mahadev konar commented on ZOOKEEPER-600:
-
henry/gustavo,
is this ready to commit?
TODO pondering about allocation behavior in zkpython may be removed
---
Key: ZOOKEEPER-600
URL: https://issues.apache.org/jira/browse/ZOOKEEPER-600
Project: Zookeeper
Issue Type: Bug
Components: contrib-bindings
Affects Versions: 3.2.1
Reporter: Gustavo Niemeyer
Assignee: Gustavo Niemeyer
Priority: Trivial
Fix For: 3.3.0
Attachments: deallocate-vector.patch
I suppose the TODO below is referring to the path variable which is passed
in as an output variable to PyArg_ParseTuple right below. The TODO may be
removed, since the code is right. Code using PyArg_ParseTuple will borrow
the reference from the calling code, since there's a stack behind the call to
the enclosing function (pyzoo_get_children in this case) which won't go away
until the function returns.
Index: src/contrib/zkpython/src/c/zookeeper.c
===
--- src/contrib/zkpython/src/c/zookeeper.c(revision 885582)
+++ src/contrib/zkpython/src/c/zookeeper.c(working copy)
@@ -774,8 +774,6 @@
static PyObject *pyzoo_get_children(PyObject *self, PyObject *args)
{
- // TO DO: Does Python copy the string or the reference? If it's the former
- // we should free the String_vector
int zkhid;
char *path;
PyObject *watcherfn = Py_None;
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (ZOOKEEPER-632) add some documentation or FAQ on how to do rolling upgrade
add some documentation or FAQ on how to do rolling upgrade -- Key: ZOOKEEPER-632 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-632 Project: Zookeeper Issue Type: Improvement Components: documentation Reporter: Patrick Hunt Priority: Minor Fix For: 3.3.0 add some detail on how to do a rolling upgrade. the benefits, etc... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
