[jira] Commented: (ZOOKEEPER-458) connect_index in zookeeper handle might get out of bound.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12781087#action_12781087 ] Hadoop QA commented on ZOOKEEPER-458: - -1 overall. Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12425744/ZOOKEEPER-458.patch against trunk revision 882744. +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/72/testReport/ Findbugs warnings: http://hudson.zones.apache.org/hudson/job/Zookeeper-Patch-h8.grid.sp2.yahoo.net/72/artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html Console output: http://hudson.zones.apache.org/hudson/job/Zookeeper-Patch-h8.grid.sp2.yahoo.net/72/console This message is automatically generated. > connect_index in zookeeper handle might get out of bound. > - > > Key: ZOOKEEPER-458 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-458 > Project: Zookeeper > Issue Type: Bug > Components: c client >Reporter: Mahadev konar >Assignee: Mahadev konar > Fix For: 3.3.0 > > Attachments: ZOOKEEPER-458.patch, ZOOKEEPER-458.patch, > ZOOKEEPER-458.patch > > > connect_index in zookeeper handle might get out of bound. the zokoeeper_init > method checks for index == count and sets it to zero. If the index becomes > greater than count, then it will go out of bounds. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-458) connect_index in zookeeper handle might get out of bound.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-458?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Steven Cheng updated ZOOKEEPER-458: --- Status: Patch Available (was: Open) > connect_index in zookeeper handle might get out of bound. > - > > Key: ZOOKEEPER-458 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-458 > Project: Zookeeper > Issue Type: Bug > Components: c client >Reporter: Mahadev konar >Assignee: Mahadev konar > Fix For: 3.3.0 > > Attachments: ZOOKEEPER-458.patch, ZOOKEEPER-458.patch, > ZOOKEEPER-458.patch > > > connect_index in zookeeper handle might get out of bound. the zokoeeper_init > method checks for index == count and sets it to zero. If the index becomes > greater than count, then it will go out of bounds. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-458) connect_index in zookeeper handle might get out of bound.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-458?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Steven Cheng updated ZOOKEEPER-458: --- Attachment: ZOOKEEPER-458.patch This patch ensures that 0 <= connect_index < addrs_count whenever connect_index is set to a non-zero value. Includes two tests that this property is maintained over disconnects. > connect_index in zookeeper handle might get out of bound. > - > > Key: ZOOKEEPER-458 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-458 > Project: Zookeeper > Issue Type: Bug > Components: c client >Reporter: Mahadev konar >Assignee: Mahadev konar > Fix For: 3.3.0 > > Attachments: ZOOKEEPER-458.patch, ZOOKEEPER-458.patch, > ZOOKEEPER-458.patch > > > connect_index in zookeeper handle might get out of bound. the zokoeeper_init > method checks for index == count and sets it to zero. If the index becomes > greater than count, then it will go out of bounds. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-587) client should log timeout negotiated with server
[ https://issues.apache.org/jira/browse/ZOOKEEPER-587?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12781074#action_12781074 ] stack commented on ZOOKEEPER-587: - If server changes the timeout on the client, yeah, for sure at least log it. Good stuff. > 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 > Fix For: 3.3.0 > > > 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.
[jira] Created: (ZOOKEEPER-588) remove unnecessary/annoying log of tostring error in Request.toString()
remove unnecessary/annoying log of tostring error in Request.toString() --- Key: ZOOKEEPER-588 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-588 Project: Zookeeper Issue Type: Bug Components: server Affects Versions: 3.2.1 Reporter: Patrick Hunt Priority: Minor Fix For: 3.3.0 Why are we logging this? It's unnecessary and just annoying afaict. We should remove it entirely. 2009-11-18 05:37:29,312 WARN org.apache.zookeeper.server.Request: Ignoring exception during toString java.nio.BufferUnderflowException at java.nio.HeapByteBuffer.get(HeapByteBuffer.java:127) at java.nio.ByteBuffer.get(ByteBuffer.java:675) at org.apache.zookeeper.server.Request.toString(Request.java:199) at java.lang.String.valueOf(String.java:2827) at java.lang.StringBuilder.append(StringBuilder.java:115) at org.apache.zookeeper.server.quorum.CommitProcessor.processRequest(CommitProcessor.java:167) at org.apache.zookeeper.server.quorum.FollowerRequestProcessor.run(FollowerRequestProcessor.java:68) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (ZOOKEEPER-587) client should log timeout negotiated with server
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 Fix For: 3.3.0 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.
[jira] Updated: (ZOOKEEPER-458) connect_index in zookeeper handle might get out of bound.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-458?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Steven Cheng updated ZOOKEEPER-458: --- Attachment: ZOOKEEPER-458.patch Tried to make some test cases that would trigger just one handle_error(), seemed like the easiest way would be to have zk connect to a non-existing server and try an operation. The first test gives me a glibc error when I run it *** glibc detected *** ./zktest-st: corrupted double-linked list: 0x08dc5d70 *** === Backtrace: = /lib/tls/i686/cmov/libc.so.6[0x401d9ff1] /lib/tls/i686/cmov/libc.so.6[0x401db899] /lib/tls/i686/cmov/libc.so.6(cfree+0x6d)[0x401de79d] [snip] [exec] make: *** [run-check] Aborted [exec] Zookeeper_operations::testOperationConnectionLoss1 : assertion This seems like a bug. I'll look into it some more later. > connect_index in zookeeper handle might get out of bound. > - > > Key: ZOOKEEPER-458 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-458 > Project: Zookeeper > Issue Type: Bug > Components: c client >Reporter: Mahadev konar >Assignee: Mahadev konar > Fix For: 3.3.0 > > Attachments: ZOOKEEPER-458.patch, ZOOKEEPER-458.patch > > > connect_index in zookeeper handle might get out of bound. the zokoeeper_init > method checks for index == count and sets it to zero. If the index becomes > greater than count, then it will go out of bounds. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-582) ZooKeeper can revert to old data when a snapshot is created outside of normal processing
[ https://issues.apache.org/jira/browse/ZOOKEEPER-582?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12780948#action_12780948 ] Hudson commented on ZOOKEEPER-582: -- Integrated in ZooKeeper-trunk #546 (See [http://hudson.zones.apache.org/hudson/job/ZooKeeper-trunk/546/]) . ZooKeeper can revert to old data when a snapshot is created outside of normal processing (ben reed and mahadev via mahadev) > ZooKeeper can revert to old data when a snapshot is created outside of normal > processing > > > Key: ZOOKEEPER-582 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-582 > Project: Zookeeper > Issue Type: Bug > Components: server >Affects Versions: 3.1.1, 3.2.1 >Reporter: Benjamin Reed >Assignee: Mahadev konar >Priority: Blocker > Fix For: 3.1.2, 3.2.2, 3.3.0 > > Attachments: test.patch, ZOOKEEPER-582.patch, ZOOKEEPER-582.patch, > ZOOKEEPER-582.patch, ZOOKEEPER-582.patch, ZOOKEEPER-582.patch, > ZOOKEEPER-582_3.1.patch, ZOOKEEPER-582_3.2.patch, ZOOKEEPER-582_3.2.patch > > > when zookeeper starts up it will restore the most recent state (latest zxid) > it finds in the data directory. unfortunately, in the quorum version of > zookeeper updates are logged using an epoch based on the latest log file in a > directory. if there is a snapshot with a higher epoch than the log files, the > zookeeper server will start logging using an epoch one higher than the > highest log file. > so if a data directory has a snapshot with an epoch of 27 and there are no > log files, zookeeper will start logging changes using epoch 1. if the cluster > restarts the state will be restored from the snapshot with the epoch of 27, > which in effect, restores old data. > normal operation of zookeeper will never result in this situation. > this does not effect standalone zookeeper. > a fix should make sure to use an epoch one higher than the current state, > whether it comes from the snapshot or log, and should include a sanity check > to make sure that a follower never connects to a leader that has a lower > epoch than its own. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-576) docs need to be updated for session moved exception and how to handle it
[ https://issues.apache.org/jira/browse/ZOOKEEPER-576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12780947#action_12780947 ] Hudson commented on ZOOKEEPER-576: -- Integrated in ZooKeeper-trunk #546 (See [http://hudson.zones.apache.org/hudson/job/ZooKeeper-trunk/546/]) . docs need to be updated for session moved exception and how to handle it > docs need to be updated for session moved exception and how to handle it > > > Key: ZOOKEEPER-576 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-576 > Project: Zookeeper > Issue Type: Bug >Reporter: Mahadev konar >Assignee: Benjamin Reed > Fix For: 3.2.2, 3.3.0 > > Attachments: ZOOKEEPER-576.patch, ZOOKEEPER-576.patch > > > the handling and implications of session moved exception should be documented. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
