[jira] Commented: (ZOOKEEPER-490) the java docs for session creation are misleading/incomplete
[ https://issues.apache.org/jira/browse/ZOOKEEPER-490?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12740504#action_12740504 ] Hadoop QA commented on ZOOKEEPER-490: - -1 overall. Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12415675/ZOOKEEPER-490.patch against trunk revision 801839. +1 @author. The patch does not contain any @author tags. -1 tests included. The patch doesn't appear to include any new or modified tests. Please justify why no tests are needed for this patch. +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-vesta.apache.org/174/testReport/ Findbugs warnings: http://hudson.zones.apache.org/hudson/job/Zookeeper-Patch-vesta.apache.org/174/artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html Console output: http://hudson.zones.apache.org/hudson/job/Zookeeper-Patch-vesta.apache.org/174/console This message is automatically generated. the java docs for session creation are misleading/incomplete Key: ZOOKEEPER-490 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-490 Project: Zookeeper Issue Type: Bug Affects Versions: 3.1.1, 3.2.0 Reporter: Patrick Hunt Assignee: Patrick Hunt Fix For: 3.2.1, 3.3.0 Attachments: ZOOKEEPER-490.patch the javadoc for ZooKeeper constructor says: * The client object will pick an arbitrary server and try to connect to it. * If failed, it will try the next one in the list, until a connection is * established, or all the servers have been tried. the or all server tried phrase is misleading, it should indicate that we retry until success, con closed, or session expired. we also need ot mention that connection is async, that constructor returns immed and you need to look for connection event in watcher -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-484) Clients get SESSION MOVED exception when switching from follower to a leader.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-484?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12740508#action_12740508 ] Hudson commented on ZOOKEEPER-484: -- Integrated in ZooKeeper-trunk #408 (See [http://hudson.zones.apache.org/hudson/job/ZooKeeper-trunk/408/]) . Clients get SESSION MOVED exception when switching from follower to a leader. (mahadev) Clients get SESSION MOVED exception when switching from follower to a leader. - Key: ZOOKEEPER-484 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-484 Project: Zookeeper Issue Type: Bug Components: server Affects Versions: 3.2.0 Reporter: Mahadev konar Assignee: Mahadev konar Priority: Blocker Fix For: 3.2.1, 3.3.0 Attachments: sessionTest.patch, ZOOKEEPER-484-3.2.patch, ZOOKEEPER-484.patch When a client is connected to follower and get disconnected and connects to a leader it gets SESSION MOVED excpetion. This is beacuse of a bug in the new feature of ZOOKEEPER-417 that we added in 3.2. All the releases before 3.2 DO NOT have this problem. The fix is to make sure the ownership of a connection gets changed when a session moves from follower to the leader. The workaround to it in 3.2.0 would be to swithc off connection from clients to the leader. take a look at *leaderServers* java property in http://hadoop.apache.org/zookeeper/docs/r3.2.0/zookeeperAdmin.html. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-483) ZK fataled on me, and ugly
[ https://issues.apache.org/jira/browse/ZOOKEEPER-483?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12740514#action_12740514 ] Hadoop QA commented on ZOOKEEPER-483: - -1 overall. Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12415695/ZOOKEEPER-483.patch against trunk revision 801839. +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-vesta.apache.org/176/console This message is automatically generated. ZK fataled on me, and ugly -- Key: ZOOKEEPER-483 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-483 Project: Zookeeper Issue Type: Bug Affects Versions: 3.1.1 Reporter: ryan rawson Assignee: Benjamin Reed Fix For: 3.2.1, 3.3.0 Attachments: zklogs.tar.gz, ZOOKEEPER-483.patch, ZOOKEEPER-483.patch here are the part of the log whereby my zookeeper instance crashed, taking 3 out of 5 down, and thus ruining the quorum for all clients: 2009-07-23 12:29:06,769 WARN org.apache.zookeeper.server.NIOServerCnxn: Exception causing close of session 0x52276d1d5161350 due to java.io.IOException: Read error 2009-07-23 12:29:00,756 WARN org.apache.zookeeper.server.quorum.Follower: Exception when following the leader java.io.EOFException at java.io.DataInputStream.readInt(DataInputStream.java:375) at org.apache.jute.BinaryInputArchive.readInt(BinaryInputArchive.java:63) at org.apache.zookeeper.server.quorum.QuorumPacket.deserialize(QuorumPacket.java:65) at org.apache.jute.BinaryInputArchive.readRecord(BinaryInputArchive.java:108) at org.apache.zookeeper.server.quorum.Follower.readPacket(Follower.java:114) at org.apache.zookeeper.server.quorum.Follower.followLeader(Follower.java:243) at org.apache.zookeeper.server.quorum.QuorumPeer.run(QuorumPeer.java:494) 2009-07-23 12:29:06,770 INFO org.apache.zookeeper.server.NIOServerCnxn: closing session:0x52276d1d5161350 NIOServerCnxn: java.nio.channels.SocketChannel[connected local=/10.20.20.151:2181 remote=/10.20.20.168:39489] 2009-07-23 12:29:06,770 INFO org.apache.zookeeper.server.NIOServerCnxn: closing session:0x12276d15dfb0578 NIOServerCnxn: java.nio.channels.SocketChannel[connected local=/10.20.20.151:2181 remote=/10.20.20.159:46797] 2009-07-23 12:29:06,771 INFO org.apache.zookeeper.server.NIOServerCnxn: closing session:0x42276d1d3fa013e NIOServerCnxn: java.nio.channels.SocketChannel[connected local=/10.20.20.151:2181 remote=/10.20.20.153:33998] 2009-07-23 12:29:06,771 WARN org.apache.zookeeper.server.NIOServerCnxn: Exception causing close of session 0x52276d1d5160593 due to java.io.IOException: Read error 2009-07-23 12:29:06,808 INFO org.apache.zookeeper.server.NIOServerCnxn: closing session:0x32276d15d2e02bb NIOServerCnxn: java.nio.channels.SocketChannel[connected local=/10.20.20.151:2181 remote=/10.20.20.158:53758] 2009-07-23 12:29:06,809 INFO org.apache.zookeeper.server.NIOServerCnxn: closing session:0x42276d1d3fa13e4 NIOServerCnxn: java.nio.channels.SocketChannel[connected local=/10.20.20.151:2181 remote=/10.20.20.154:58681] 2009-07-23 12:29:06,809 INFO org.apache.zookeeper.server.NIOServerCnxn: closing session:0x22276d15e691382 NIOServerCnxn: java.nio.channels.SocketChannel[connected local=/10.20.20.151:2181 remote=/10.20.20.162:59967] 2009-07-23 12:29:06,809 INFO org.apache.zookeeper.server.NIOServerCnxn: closing session:0x12276d15dfb1354 NIOServerCnxn: java.nio.channels.SocketChannel[connected local=/10.20.20.151:2181 remote=/10.20.20.163:49957] 2009-07-23 12:29:06,809 INFO org.apache.zookeeper.server.NIOServerCnxn: closing session:0x42276d1d3fa13cd NIOServerCnxn: java.nio.channels.SocketChannel[connected local=/10.20.20.151:2181 remote=/10.20.20.150:34212] 2009-07-23 12:29:06,809 INFO org.apache.zookeeper.server.NIOServerCnxn: closing session:0x22276d15e691383 NIOServerCnxn: java.nio.channels.SocketChannel[connected local=/10.20.20.151:2181 remote=/10.20.20.159:46813] 2009-07-23 12:29:06,809 INFO org.apache.zookeeper.server.NIOServerCnxn: closing session:0x12276d15dfb0350 NIOServerCnxn: java.nio.channels.SocketChannel[connected local=/10.20.20.151:2181 remote=/10.20.20.162:59956] 2009-07-23 12:29:06,809 INFO org.apache.zookeeper.server.NIOServerCnxn: closing session:0x32276d15d2e139b NIOServerCnxn: java.nio.channels.SocketChannel[connected local=/10.20.20.151:2181 remote=/10.20.20.156:55138] 2009-07-23 12:29:06,809 INFO org.apache.zookeeper.server.NIOServerCnxn: closing
[jira] Updated: (ZOOKEEPER-498) Unending Leader Elections : WAN configuration
[ https://issues.apache.org/jira/browse/ZOOKEEPER-498?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Flavio Paiva Junqueira updated ZOOKEEPER-498: - Attachment: ZOOKEEPER-498.patch This patch includes documentation a reimplementation of HierarchicalQuorumTest. The new implementation of HierarchicalQuorumTest is based on QuorumBase, the main differences being that HQT uses hierarchical quorums and FLE for leader election. It uses testHammerBasic of ClientTest to verify that upon the election of a leader the ensemble works as expected. When I initially implemented the test, it was failing to terminate due to FLE failing to shutdown properly. I implemented some modifications to FLE to make sure that it shuts down correctly. Unending Leader Elections : WAN configuration - Key: ZOOKEEPER-498 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-498 Project: Zookeeper Issue Type: Bug Components: leaderElection Affects Versions: 3.2.0 Environment: Each machine: CentOS 5.2 64-bit 2GB ram java version 1.6.0_13 Java(TM) SE Runtime Environment (build 1.6.0_13-b03) Java HotSpot(TM) 64-Bit Server VM (build 11.3-b02, mixed Network Topology: DC : central data center POD(N): remote data center Zookeeper Topology: Leaders may be elected only in DC (weight = 1) Only followers are elected in PODS (weight = 0) Reporter: Todd Greenwood-Geer Assignee: Flavio Paiva Junqueira Priority: Critical Fix For: 3.2.1, 3.3.0 Attachments: dc-zook-logs-01.tar.gz, pod-zook-logs-01.tar.gz, zk498-test.tar.gz, zoo.cfg, ZOOKEEPER-498.patch, ZOOKEEPER-498.patch, ZOOKEEPER-498.patch In a WAN configuration, ZooKeeper is endlessly electing, terminating, and re-electing a ZooKeeper leader. The WAN configuration involves two groups, a central DC group of ZK servers that have a voting weight = 1, and a group of servers in remote pods with a voting weight of 0. What we expect to see is leaders elected only in the DC, and the pods to contain only followers. What we are seeing is a continuous cycling of leaders. We have seen this consistently with 3.2.0, 3.2.0 + recommended patches (473, 479, 481, 491), and now release 3.2.1. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-498) Unending Leader Elections : WAN configuration
[ https://issues.apache.org/jira/browse/ZOOKEEPER-498?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Flavio Paiva Junqueira updated ZOOKEEPER-498: - Status: Patch Available (was: Open) Unending Leader Elections : WAN configuration - Key: ZOOKEEPER-498 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-498 Project: Zookeeper Issue Type: Bug Components: leaderElection Affects Versions: 3.2.0 Environment: Each machine: CentOS 5.2 64-bit 2GB ram java version 1.6.0_13 Java(TM) SE Runtime Environment (build 1.6.0_13-b03) Java HotSpot(TM) 64-Bit Server VM (build 11.3-b02, mixed Network Topology: DC : central data center POD(N): remote data center Zookeeper Topology: Leaders may be elected only in DC (weight = 1) Only followers are elected in PODS (weight = 0) Reporter: Todd Greenwood-Geer Assignee: Flavio Paiva Junqueira Priority: Critical Fix For: 3.2.1, 3.3.0 Attachments: dc-zook-logs-01.tar.gz, pod-zook-logs-01.tar.gz, zk498-test.tar.gz, zoo.cfg, ZOOKEEPER-498.patch, ZOOKEEPER-498.patch, ZOOKEEPER-498.patch In a WAN configuration, ZooKeeper is endlessly electing, terminating, and re-electing a ZooKeeper leader. The WAN configuration involves two groups, a central DC group of ZK servers that have a voting weight = 1, and a group of servers in remote pods with a voting weight of 0. What we expect to see is leaders elected only in the DC, and the pods to contain only followers. What we are seeing is a continuous cycling of leaders. We have seen this consistently with 3.2.0, 3.2.0 + recommended patches (473, 479, 481, 491), and now release 3.2.1. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-501) CnxManagerTest failed on hudson
[ https://issues.apache.org/jira/browse/ZOOKEEPER-501?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Flavio Paiva Junqueira updated ZOOKEEPER-501: - Attachment: ZOOKEEPER-501.patch Since I cannot reproduce, I tried to come up with an explanation for the failure of this test. I suspect that due to timing, one cnx manager tried to connect to the other before the other was available to receive connections. Consequently, the patch I propose retries to connect a number of times. It also times out itself instead of waiting for junit to kill it. CnxManagerTest failed on hudson --- Key: ZOOKEEPER-501 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-501 Project: Zookeeper Issue Type: Bug Reporter: Flavio Paiva Junqueira Fix For: 3.2.1, 3.3.0 Attachments: CnxnManagerTest.log, ZOOKEEPER-501.patch It timed out according to the console output: http://hudson.zones.apache.org/hudson/job/ZooKeeper-trunk/406/testReport/org.apache.zookeeper.test/CnxManagerTest/testCnxManager/ -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-501) CnxManagerTest failed on hudson
[ https://issues.apache.org/jira/browse/ZOOKEEPER-501?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Flavio Paiva Junqueira updated ZOOKEEPER-501: - Status: Patch Available (was: Open) CnxManagerTest failed on hudson --- Key: ZOOKEEPER-501 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-501 Project: Zookeeper Issue Type: Bug Reporter: Flavio Paiva Junqueira Fix For: 3.2.1, 3.3.0 Attachments: CnxnManagerTest.log, ZOOKEEPER-501.patch It timed out according to the console output: http://hudson.zones.apache.org/hudson/job/ZooKeeper-trunk/406/testReport/org.apache.zookeeper.test/CnxManagerTest/testCnxManager/ -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (ZOOKEEPER-501) CnxManagerTest failed on hudson
[ https://issues.apache.org/jira/browse/ZOOKEEPER-501?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Hunt reassigned ZOOKEEPER-501: -- Assignee: Flavio Paiva Junqueira CnxManagerTest failed on hudson --- Key: ZOOKEEPER-501 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-501 Project: Zookeeper Issue Type: Bug Reporter: Flavio Paiva Junqueira Assignee: Flavio Paiva Junqueira Fix For: 3.2.1, 3.3.0 Attachments: CnxnManagerTest.log, ZOOKEEPER-501.patch It timed out according to the console output: http://hudson.zones.apache.org/hudson/job/ZooKeeper-trunk/406/testReport/org.apache.zookeeper.test/CnxManagerTest/testCnxManager/ -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (ZOOKEEPER-504) ClassCastException in LedgerManagementProcessor
ClassCastException in LedgerManagementProcessor --- Key: ZOOKEEPER-504 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-504 Project: Zookeeper Issue Type: Bug Components: contrib-bookkeeper Reporter: Utkarsh Srivastava java.lang.ClassCastException: org.apache.bookkeeper.client.LedgerManagementProcessor$OpenLedgerOp cannot be cast to org.apache.bookkeeper.client.LedgerManagementProcessor$CloseLedgerOp at org.apache.bookkeeper.client.LedgerManagementProcessor.processResult(LedgerManagementProcessor.java:1083) This seems to be happening because its a nested switch case statement. And the OPEN: case, doesn't ever call a break. It only calls a break from the inner switch-case and hence falls through into the CLOSE: case. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-498) Unending Leader Elections : WAN configuration
[ https://issues.apache.org/jira/browse/ZOOKEEPER-498?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12740668#action_12740668 ] Hadoop QA commented on ZOOKEEPER-498: - +1 overall. Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12415848/ZOOKEEPER-498.patch against trunk revision 802108. +1 @author. The patch does not contain any @author tags. +1 tests included. The patch appears to include 6 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-vesta.apache.org/177/testReport/ Findbugs warnings: http://hudson.zones.apache.org/hudson/job/Zookeeper-Patch-vesta.apache.org/177/artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html Console output: http://hudson.zones.apache.org/hudson/job/Zookeeper-Patch-vesta.apache.org/177/console This message is automatically generated. Unending Leader Elections : WAN configuration - Key: ZOOKEEPER-498 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-498 Project: Zookeeper Issue Type: Bug Components: leaderElection Affects Versions: 3.2.0 Environment: Each machine: CentOS 5.2 64-bit 2GB ram java version 1.6.0_13 Java(TM) SE Runtime Environment (build 1.6.0_13-b03) Java HotSpot(TM) 64-Bit Server VM (build 11.3-b02, mixed Network Topology: DC : central data center POD(N): remote data center Zookeeper Topology: Leaders may be elected only in DC (weight = 1) Only followers are elected in PODS (weight = 0) Reporter: Todd Greenwood-Geer Assignee: Flavio Paiva Junqueira Priority: Critical Fix For: 3.2.1, 3.3.0 Attachments: dc-zook-logs-01.tar.gz, pod-zook-logs-01.tar.gz, zk498-test.tar.gz, zoo.cfg, ZOOKEEPER-498.patch, ZOOKEEPER-498.patch, ZOOKEEPER-498.patch In a WAN configuration, ZooKeeper is endlessly electing, terminating, and re-electing a ZooKeeper leader. The WAN configuration involves two groups, a central DC group of ZK servers that have a voting weight = 1, and a group of servers in remote pods with a voting weight of 0. What we expect to see is leaders elected only in the DC, and the pods to contain only followers. What we are seeing is a continuous cycling of leaders. We have seen this consistently with 3.2.0, 3.2.0 + recommended patches (473, 479, 481, 491), and now release 3.2.1. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-501) CnxManagerTest failed on hudson
[ https://issues.apache.org/jira/browse/ZOOKEEPER-501?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12740708#action_12740708 ] Mahadev konar commented on ZOOKEEPER-501: - +1 the patch passes the tests for me... tahnks flavio ... CnxManagerTest failed on hudson --- Key: ZOOKEEPER-501 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-501 Project: Zookeeper Issue Type: Bug Reporter: Flavio Paiva Junqueira Assignee: Flavio Paiva Junqueira Fix For: 3.2.1, 3.3.0 Attachments: CnxnManagerTest.log, ZOOKEEPER-501.patch It timed out according to the console output: http://hudson.zones.apache.org/hudson/job/ZooKeeper-trunk/406/testReport/org.apache.zookeeper.test/CnxManagerTest/testCnxManager/ -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-498) Unending Leader Elections : WAN configuration
[ https://issues.apache.org/jira/browse/ZOOKEEPER-498?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12740720#action_12740720 ] Patrick Hunt commented on ZOOKEEPER-498: fwiw: I tested this out on trunk with a few diff configurations and it seems to have fixed the issue(s) seen before! 9 servers : OK 9 servers: weight 1:1:1:1:1:0:0:0:0 : OK 9 servers: weight 1:1:1:1:1:0:0:0:0 3 groups 1:2:3:4:5 6:7 8:9 : OK 9 servers: weight 1:1:1:1:1:0:0:0:0 1 group 1:2:3:4:5:6:7:8:9 : OK Unending Leader Elections : WAN configuration - Key: ZOOKEEPER-498 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-498 Project: Zookeeper Issue Type: Bug Components: leaderElection Affects Versions: 3.2.0 Environment: Each machine: CentOS 5.2 64-bit 2GB ram java version 1.6.0_13 Java(TM) SE Runtime Environment (build 1.6.0_13-b03) Java HotSpot(TM) 64-Bit Server VM (build 11.3-b02, mixed Network Topology: DC : central data center POD(N): remote data center Zookeeper Topology: Leaders may be elected only in DC (weight = 1) Only followers are elected in PODS (weight = 0) Reporter: Todd Greenwood-Geer Assignee: Flavio Paiva Junqueira Priority: Critical Fix For: 3.2.1, 3.3.0 Attachments: dc-zook-logs-01.tar.gz, pod-zook-logs-01.tar.gz, zk498-test.tar.gz, zoo.cfg, ZOOKEEPER-498.patch, ZOOKEEPER-498.patch, ZOOKEEPER-498.patch In a WAN configuration, ZooKeeper is endlessly electing, terminating, and re-electing a ZooKeeper leader. The WAN configuration involves two groups, a central DC group of ZK servers that have a voting weight = 1, and a group of servers in remote pods with a voting weight of 0. What we expect to see is leaders elected only in the DC, and the pods to contain only followers. What we are seeing is a continuous cycling of leaders. We have seen this consistently with 3.2.0, 3.2.0 + recommended patches (473, 479, 481, 491), and now release 3.2.1. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-501) CnxManagerTest failed on hudson
[ https://issues.apache.org/jira/browse/ZOOKEEPER-501?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12740721#action_12740721 ] Mahadev konar commented on ZOOKEEPER-501: - [exec] +1 overall. [exec] +1 @author. The patch does not contain any @author tags. [exec] +1 tests included. The patch appears to include 3 new or modified tests. [exec] +1 javadoc. The javadoc tool did not generate any warning messages. [exec] +1 javac. The applied patch does not increase the total number of javac compiler warnings. [exec] +1 findbugs. The patch does not introduce any new Findbugs warnings. [exec] +1 release audit. The applied patch does not increase the total number of release audit warnings. ran ant test-patch on my local machine CnxManagerTest failed on hudson --- Key: ZOOKEEPER-501 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-501 Project: Zookeeper Issue Type: Bug Reporter: Flavio Paiva Junqueira Assignee: Flavio Paiva Junqueira Fix For: 3.2.1, 3.3.0 Attachments: CnxnManagerTest.log, ZOOKEEPER-501.patch It timed out according to the console output: http://hudson.zones.apache.org/hudson/job/ZooKeeper-trunk/406/testReport/org.apache.zookeeper.test/CnxManagerTest/testCnxManager/ -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-498) Unending Leader Elections : WAN configuration
[ https://issues.apache.org/jira/browse/ZOOKEEPER-498?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12740731#action_12740731 ] Todd Greenwood-Geer commented on ZOOKEEPER-498: --- Patrick, Thanks for the update. I'm closely following the dev alias and appreciate the effort the ZK team is putting in. For the time being, I'll stick with 3.1.1 and solve our WAN issues with an ensemble synchronizer. I'm in the middle of writing that bit right now. BTW - Should I succeed in convincing my company to allow me to open source various components that I've written (on top of zookeeper), what is the process for that? -Todd Unending Leader Elections : WAN configuration - Key: ZOOKEEPER-498 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-498 Project: Zookeeper Issue Type: Bug Components: leaderElection Affects Versions: 3.2.0 Environment: Each machine: CentOS 5.2 64-bit 2GB ram java version 1.6.0_13 Java(TM) SE Runtime Environment (build 1.6.0_13-b03) Java HotSpot(TM) 64-Bit Server VM (build 11.3-b02, mixed Network Topology: DC : central data center POD(N): remote data center Zookeeper Topology: Leaders may be elected only in DC (weight = 1) Only followers are elected in PODS (weight = 0) Reporter: Todd Greenwood-Geer Assignee: Flavio Paiva Junqueira Priority: Critical Fix For: 3.2.1, 3.3.0 Attachments: dc-zook-logs-01.tar.gz, pod-zook-logs-01.tar.gz, zk498-test.tar.gz, zoo.cfg, ZOOKEEPER-498.patch, ZOOKEEPER-498.patch, ZOOKEEPER-498.patch In a WAN configuration, ZooKeeper is endlessly electing, terminating, and re-electing a ZooKeeper leader. The WAN configuration involves two groups, a central DC group of ZK servers that have a voting weight = 1, and a group of servers in remote pods with a voting weight of 0. What we expect to see is leaders elected only in the DC, and the pods to contain only followers. What we are seeing is a continuous cycling of leaders. We have seen this consistently with 3.2.0, 3.2.0 + recommended patches (473, 479, 481, 491), and now release 3.2.1. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-498) Unending Leader Elections : WAN configuration
[ https://issues.apache.org/jira/browse/ZOOKEEPER-498?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12740732#action_12740732 ] Patrick Hunt commented on ZOOKEEPER-498: I also tried this (todd's original configuration) and it also works with this patch: 9 servers: weight 1:1:1:1:1:0:0:0:0 2 groups 1:2:3:4:5 6:7:8:9 : OK server 1 config: - tickTime=2000 initLimit=10 syncLimit=5 dataDir=./s1/data clientPort=2181 electionAlg=3 server.1=localhost:3181:4181 server.2=localhost:3182:4182 server.3=localhost:3183:4183 server.4=localhost:3184:4184 server.5=localhost:3185:4185 server.6=localhost:3186:4186 server.7=localhost:3187:4187 server.8=localhost:3188:4188 server.9=localhost:3189:4189 weight.1=1 weight.2=1 weight.3=1 weight.4=1 weight.5=1 weight.6=0 weight.7=0 weight.8=0 weight.9=0 group.1=1:2:3:4:5 group.2=6:7:8:9 Unending Leader Elections : WAN configuration - Key: ZOOKEEPER-498 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-498 Project: Zookeeper Issue Type: Bug Components: leaderElection Affects Versions: 3.2.0 Environment: Each machine: CentOS 5.2 64-bit 2GB ram java version 1.6.0_13 Java(TM) SE Runtime Environment (build 1.6.0_13-b03) Java HotSpot(TM) 64-Bit Server VM (build 11.3-b02, mixed Network Topology: DC : central data center POD(N): remote data center Zookeeper Topology: Leaders may be elected only in DC (weight = 1) Only followers are elected in PODS (weight = 0) Reporter: Todd Greenwood-Geer Assignee: Flavio Paiva Junqueira Priority: Critical Fix For: 3.2.1, 3.3.0 Attachments: dc-zook-logs-01.tar.gz, pod-zook-logs-01.tar.gz, zk498-test.tar.gz, zoo.cfg, ZOOKEEPER-498.patch, ZOOKEEPER-498.patch, ZOOKEEPER-498.patch In a WAN configuration, ZooKeeper is endlessly electing, terminating, and re-electing a ZooKeeper leader. The WAN configuration involves two groups, a central DC group of ZK servers that have a voting weight = 1, and a group of servers in remote pods with a voting weight of 0. What we expect to see is leaders elected only in the DC, and the pods to contain only followers. What we are seeing is a continuous cycling of leaders. We have seen this consistently with 3.2.0, 3.2.0 + recommended patches (473, 479, 481, 491), and now release 3.2.1. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-501) CnxManagerTest failed on hudson
[ https://issues.apache.org/jira/browse/ZOOKEEPER-501?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mahadev konar updated ZOOKEEPER-501: Resolution: Fixed Hadoop Flags: [Reviewed] Status: Resolved (was: Patch Available) I just committed this. thanks flavio... CnxManagerTest failed on hudson --- Key: ZOOKEEPER-501 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-501 Project: Zookeeper Issue Type: Bug Reporter: Flavio Paiva Junqueira Assignee: Flavio Paiva Junqueira Fix For: 3.2.1, 3.3.0 Attachments: CnxnManagerTest.log, ZOOKEEPER-501.patch It timed out according to the console output: http://hudson.zones.apache.org/hudson/job/ZooKeeper-trunk/406/testReport/org.apache.zookeeper.test/CnxManagerTest/testCnxManager/ -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-498) Unending Leader Elections : WAN configuration
[ https://issues.apache.org/jira/browse/ZOOKEEPER-498?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12740736#action_12740736 ] Patrick Hunt commented on ZOOKEEPER-498: Todd, we appreciate your help and patience while we straighten this issue out. Thanks! Unending Leader Elections : WAN configuration - Key: ZOOKEEPER-498 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-498 Project: Zookeeper Issue Type: Bug Components: leaderElection Affects Versions: 3.2.0 Environment: Each machine: CentOS 5.2 64-bit 2GB ram java version 1.6.0_13 Java(TM) SE Runtime Environment (build 1.6.0_13-b03) Java HotSpot(TM) 64-Bit Server VM (build 11.3-b02, mixed Network Topology: DC : central data center POD(N): remote data center Zookeeper Topology: Leaders may be elected only in DC (weight = 1) Only followers are elected in PODS (weight = 0) Reporter: Todd Greenwood-Geer Assignee: Flavio Paiva Junqueira Priority: Critical Fix For: 3.2.1, 3.3.0 Attachments: dc-zook-logs-01.tar.gz, pod-zook-logs-01.tar.gz, zk498-test.tar.gz, zoo.cfg, ZOOKEEPER-498.patch, ZOOKEEPER-498.patch, ZOOKEEPER-498.patch In a WAN configuration, ZooKeeper is endlessly electing, terminating, and re-electing a ZooKeeper leader. The WAN configuration involves two groups, a central DC group of ZK servers that have a voting weight = 1, and a group of servers in remote pods with a voting weight of 0. What we expect to see is leaders elected only in the DC, and the pods to contain only followers. What we are seeing is a continuous cycling of leaders. We have seen this consistently with 3.2.0, 3.2.0 + recommended patches (473, 479, 481, 491), and now release 3.2.1. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-498) Unending Leader Elections : WAN configuration
[ https://issues.apache.org/jira/browse/ZOOKEEPER-498?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12740737#action_12740737 ] Patrick Hunt commented on ZOOKEEPER-498: Todd, the basic process from our end is that you should enter a JIRA and attach a patch. if you are contributing outside core, then you prolly want to add your stuff to src/contrib http://wiki.apache.org/hadoop/ZooKeeper/HowToContribute Unending Leader Elections : WAN configuration - Key: ZOOKEEPER-498 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-498 Project: Zookeeper Issue Type: Bug Components: leaderElection Affects Versions: 3.2.0 Environment: Each machine: CentOS 5.2 64-bit 2GB ram java version 1.6.0_13 Java(TM) SE Runtime Environment (build 1.6.0_13-b03) Java HotSpot(TM) 64-Bit Server VM (build 11.3-b02, mixed Network Topology: DC : central data center POD(N): remote data center Zookeeper Topology: Leaders may be elected only in DC (weight = 1) Only followers are elected in PODS (weight = 0) Reporter: Todd Greenwood-Geer Assignee: Flavio Paiva Junqueira Priority: Critical Fix For: 3.2.1, 3.3.0 Attachments: dc-zook-logs-01.tar.gz, pod-zook-logs-01.tar.gz, zk498-test.tar.gz, zoo.cfg, ZOOKEEPER-498.patch, ZOOKEEPER-498.patch, ZOOKEEPER-498.patch In a WAN configuration, ZooKeeper is endlessly electing, terminating, and re-electing a ZooKeeper leader. The WAN configuration involves two groups, a central DC group of ZK servers that have a voting weight = 1, and a group of servers in remote pods with a voting weight of 0. What we expect to see is leaders elected only in the DC, and the pods to contain only followers. What we are seeing is a continuous cycling of leaders. We have seen this consistently with 3.2.0, 3.2.0 + recommended patches (473, 479, 481, 491), and now release 3.2.1. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-504) ClassCastException in LedgerManagementProcessor
[ https://issues.apache.org/jira/browse/ZOOKEEPER-504?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Utkarsh Srivastava updated ZOOKEEPER-504: - Status: Open (was: Patch Available) ClassCastException in LedgerManagementProcessor --- Key: ZOOKEEPER-504 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-504 Project: Zookeeper Issue Type: Bug Components: contrib-bookkeeper Affects Versions: 3.2.0 Reporter: Utkarsh Srivastava java.lang.ClassCastException: org.apache.bookkeeper.client.LedgerManagementProcessor$OpenLedgerOp cannot be cast to org.apache.bookkeeper.client.LedgerManagementProcessor$CloseLedgerOp at org.apache.bookkeeper.client.LedgerManagementProcessor.processResult(LedgerManagementProcessor.java:1083) This seems to be happening because its a nested switch case statement. And the OPEN: case, doesn't ever call a break. It only calls a break from the inner switch-case and hence falls through into the CLOSE: case. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-504) ClassCastException in LedgerManagementProcessor
[ https://issues.apache.org/jira/browse/ZOOKEEPER-504?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Utkarsh Srivastava updated ZOOKEEPER-504: - Affects Version/s: 3.2.0 Status: Patch Available (was: Open) The case that reproduces all these problem is when a client tries to open a ledger that has not been properly closed. After fixing the original classcast problem and chasing further, ran into couple more issues. Attaching the patch for 3 problems that we found. Still cant get the case to work as we get a ZK error in the asyncOpen callback, ClassCastException in LedgerManagementProcessor --- Key: ZOOKEEPER-504 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-504 Project: Zookeeper Issue Type: Bug Components: contrib-bookkeeper Affects Versions: 3.2.0 Reporter: Utkarsh Srivastava java.lang.ClassCastException: org.apache.bookkeeper.client.LedgerManagementProcessor$OpenLedgerOp cannot be cast to org.apache.bookkeeper.client.LedgerManagementProcessor$CloseLedgerOp at org.apache.bookkeeper.client.LedgerManagementProcessor.processResult(LedgerManagementProcessor.java:1083) This seems to be happening because its a nested switch case statement. And the OPEN: case, doesn't ever call a break. It only calls a break from the inner switch-case and hence falls through into the CLOSE: case. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-504) ClassCastException in LedgerManagementProcessor
[ https://issues.apache.org/jira/browse/ZOOKEEPER-504?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Utkarsh Srivastava updated ZOOKEEPER-504: - Attachment: ZOOKEEPER-504.patch ClassCastException in LedgerManagementProcessor --- Key: ZOOKEEPER-504 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-504 Project: Zookeeper Issue Type: Bug Components: contrib-bookkeeper Affects Versions: 3.2.0 Reporter: Utkarsh Srivastava Attachments: ZOOKEEPER-504.patch java.lang.ClassCastException: org.apache.bookkeeper.client.LedgerManagementProcessor$OpenLedgerOp cannot be cast to org.apache.bookkeeper.client.LedgerManagementProcessor$CloseLedgerOp at org.apache.bookkeeper.client.LedgerManagementProcessor.processResult(LedgerManagementProcessor.java:1083) This seems to be happening because its a nested switch case statement. And the OPEN: case, doesn't ever call a break. It only calls a break from the inner switch-case and hence falls through into the CLOSE: case. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-504) ClassCastException in LedgerManagementProcessor
[ https://issues.apache.org/jira/browse/ZOOKEEPER-504?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Utkarsh Srivastava updated ZOOKEEPER-504: - Status: Patch Available (was: Open) ClassCastException in LedgerManagementProcessor --- Key: ZOOKEEPER-504 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-504 Project: Zookeeper Issue Type: Bug Components: contrib-bookkeeper Affects Versions: 3.2.0 Reporter: Utkarsh Srivastava Attachments: ZOOKEEPER-504.patch java.lang.ClassCastException: org.apache.bookkeeper.client.LedgerManagementProcessor$OpenLedgerOp cannot be cast to org.apache.bookkeeper.client.LedgerManagementProcessor$CloseLedgerOp at org.apache.bookkeeper.client.LedgerManagementProcessor.processResult(LedgerManagementProcessor.java:1083) This seems to be happening because its a nested switch case statement. And the OPEN: case, doesn't ever call a break. It only calls a break from the inner switch-case and hence falls through into the CLOSE: case. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-498) Unending Leader Elections : WAN configuration
[ https://issues.apache.org/jira/browse/ZOOKEEPER-498?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Hunt updated ZOOKEEPER-498: --- Status: Open (was: Patch Available) cancelling patch - I'm still seeing logs at incorrect level: s9/zoo.log:2009-08-07 13:54:16,154 - ERROR [WorkerSender Thread:quorumcnxmana...@332] - There is a connection for server 8 s9/zoo.log:2009-08-07 13:54:16,244 - ERROR [WorkerSender Thread:quorumcnxmana...@332] - There is a connection for server 6 s9/zoo.log:2009-08-07 13:54:16,614 - ERROR [WorkerSender Thread:quorumcnxmana...@332] - There is a connection for server 7 s9/zoo.log:2009-08-07 13:55:47,355 - ERROR [WorkerSender Thread:quorumcnxmana...@332] - There is a connection for server 1 Unending Leader Elections : WAN configuration - Key: ZOOKEEPER-498 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-498 Project: Zookeeper Issue Type: Bug Components: leaderElection Affects Versions: 3.2.0 Environment: Each machine: CentOS 5.2 64-bit 2GB ram java version 1.6.0_13 Java(TM) SE Runtime Environment (build 1.6.0_13-b03) Java HotSpot(TM) 64-Bit Server VM (build 11.3-b02, mixed Network Topology: DC : central data center POD(N): remote data center Zookeeper Topology: Leaders may be elected only in DC (weight = 1) Only followers are elected in PODS (weight = 0) Reporter: Todd Greenwood-Geer Assignee: Flavio Paiva Junqueira Priority: Critical Fix For: 3.2.1, 3.3.0 Attachments: dc-zook-logs-01.tar.gz, pod-zook-logs-01.tar.gz, zk498-test.tar.gz, zoo.cfg, ZOOKEEPER-498.patch, ZOOKEEPER-498.patch, ZOOKEEPER-498.patch In a WAN configuration, ZooKeeper is endlessly electing, terminating, and re-electing a ZooKeeper leader. The WAN configuration involves two groups, a central DC group of ZK servers that have a voting weight = 1, and a group of servers in remote pods with a voting weight of 0. What we expect to see is leaders elected only in the DC, and the pods to contain only followers. What we are seeing is a continuous cycling of leaders. We have seen this consistently with 3.2.0, 3.2.0 + recommended patches (473, 479, 481, 491), and now release 3.2.1. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-504) ClassCastException in LedgerManagementProcessor
[ https://issues.apache.org/jira/browse/ZOOKEEPER-504?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Utkarsh Srivastava updated ZOOKEEPER-504: - Attachment: ZOOKEEPER-504.patch There seem to be plenty of other problems with LedgerManagementProcessor. In this patch, I fix some of them just by visual inspection, and not by writing comprehensive test case. One pattern I saw was that after calling the callback for ops, there was no return statement, and the code would go on to do other things. I fixed all occurrences of those bugs. But my create callback is still called multiple time (ZOOKEEPER-502), and I still cant open a ledger that was not properly closed. ClassCastException in LedgerManagementProcessor --- Key: ZOOKEEPER-504 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-504 Project: Zookeeper Issue Type: Bug Components: contrib-bookkeeper Affects Versions: 3.2.0 Reporter: Utkarsh Srivastava Attachments: ZOOKEEPER-504.patch, ZOOKEEPER-504.patch java.lang.ClassCastException: org.apache.bookkeeper.client.LedgerManagementProcessor$OpenLedgerOp cannot be cast to org.apache.bookkeeper.client.LedgerManagementProcessor$CloseLedgerOp at org.apache.bookkeeper.client.LedgerManagementProcessor.processResult(LedgerManagementProcessor.java:1083) This seems to be happening because its a nested switch case statement. And the OPEN: case, doesn't ever call a break. It only calls a break from the inner switch-case and hence falls through into the CLOSE: case. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-504) ClassCastException in LedgerManagementProcessor
[ https://issues.apache.org/jira/browse/ZOOKEEPER-504?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Utkarsh Srivastava updated ZOOKEEPER-504: - Attachment: ZOOKEEPER-504.1.patch Oops attached wrong file. ClassCastException in LedgerManagementProcessor --- Key: ZOOKEEPER-504 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-504 Project: Zookeeper Issue Type: Bug Components: contrib-bookkeeper Affects Versions: 3.2.0 Reporter: Utkarsh Srivastava Attachments: ZOOKEEPER-504.1.patch, ZOOKEEPER-504.patch, ZOOKEEPER-504.patch java.lang.ClassCastException: org.apache.bookkeeper.client.LedgerManagementProcessor$OpenLedgerOp cannot be cast to org.apache.bookkeeper.client.LedgerManagementProcessor$CloseLedgerOp at org.apache.bookkeeper.client.LedgerManagementProcessor.processResult(LedgerManagementProcessor.java:1083) This seems to be happening because its a nested switch case statement. And the OPEN: case, doesn't ever call a break. It only calls a break from the inner switch-case and hence falls through into the CLOSE: case. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-498) Unending Leader Elections : WAN configuration
[ https://issues.apache.org/jira/browse/ZOOKEEPER-498?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Flavio Paiva Junqueira updated ZOOKEEPER-498: - Status: Patch Available (was: Open) Unending Leader Elections : WAN configuration - Key: ZOOKEEPER-498 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-498 Project: Zookeeper Issue Type: Bug Components: leaderElection Affects Versions: 3.2.0 Environment: Each machine: CentOS 5.2 64-bit 2GB ram java version 1.6.0_13 Java(TM) SE Runtime Environment (build 1.6.0_13-b03) Java HotSpot(TM) 64-Bit Server VM (build 11.3-b02, mixed Network Topology: DC : central data center POD(N): remote data center Zookeeper Topology: Leaders may be elected only in DC (weight = 1) Only followers are elected in PODS (weight = 0) Reporter: Todd Greenwood-Geer Assignee: Flavio Paiva Junqueira Priority: Critical Fix For: 3.2.1, 3.3.0 Attachments: dc-zook-logs-01.tar.gz, pod-zook-logs-01.tar.gz, zk498-test.tar.gz, zoo.cfg, ZOOKEEPER-498.patch, ZOOKEEPER-498.patch, ZOOKEEPER-498.patch, ZOOKEEPER-498.patch In a WAN configuration, ZooKeeper is endlessly electing, terminating, and re-electing a ZooKeeper leader. The WAN configuration involves two groups, a central DC group of ZK servers that have a voting weight = 1, and a group of servers in remote pods with a voting weight of 0. What we expect to see is leaders elected only in the DC, and the pods to contain only followers. What we are seeing is a continuous cycling of leaders. We have seen this consistently with 3.2.0, 3.2.0 + recommended patches (473, 479, 481, 491), and now release 3.2.1. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-498) Unending Leader Elections : WAN configuration
[ https://issues.apache.org/jira/browse/ZOOKEEPER-498?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Flavio Paiva Junqueira updated ZOOKEEPER-498: - Attachment: ZOOKEEPER-498.patch Fixing log level. Unending Leader Elections : WAN configuration - Key: ZOOKEEPER-498 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-498 Project: Zookeeper Issue Type: Bug Components: leaderElection Affects Versions: 3.2.0 Environment: Each machine: CentOS 5.2 64-bit 2GB ram java version 1.6.0_13 Java(TM) SE Runtime Environment (build 1.6.0_13-b03) Java HotSpot(TM) 64-Bit Server VM (build 11.3-b02, mixed Network Topology: DC : central data center POD(N): remote data center Zookeeper Topology: Leaders may be elected only in DC (weight = 1) Only followers are elected in PODS (weight = 0) Reporter: Todd Greenwood-Geer Assignee: Flavio Paiva Junqueira Priority: Critical Fix For: 3.2.1, 3.3.0 Attachments: dc-zook-logs-01.tar.gz, pod-zook-logs-01.tar.gz, zk498-test.tar.gz, zoo.cfg, ZOOKEEPER-498.patch, ZOOKEEPER-498.patch, ZOOKEEPER-498.patch, ZOOKEEPER-498.patch In a WAN configuration, ZooKeeper is endlessly electing, terminating, and re-electing a ZooKeeper leader. The WAN configuration involves two groups, a central DC group of ZK servers that have a voting weight = 1, and a group of servers in remote pods with a voting weight of 0. What we expect to see is leaders elected only in the DC, and the pods to contain only followers. What we are seeing is a continuous cycling of leaders. We have seen this consistently with 3.2.0, 3.2.0 + recommended patches (473, 479, 481, 491), and now release 3.2.1. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-504) ClassCastException in LedgerManagementProcessor
[ https://issues.apache.org/jira/browse/ZOOKEEPER-504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12740822#action_12740822 ] Hadoop QA commented on ZOOKEEPER-504: - -1 overall. Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12415907/ZOOKEEPER-504.1.patch against trunk revision 802188. +1 @author. The patch does not contain any @author tags. -1 tests included. The patch doesn't appear to include any new or modified tests. Please justify why no tests are needed for this patch. +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-vesta.apache.org/179/testReport/ Findbugs warnings: http://hudson.zones.apache.org/hudson/job/Zookeeper-Patch-vesta.apache.org/179/artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html Console output: http://hudson.zones.apache.org/hudson/job/Zookeeper-Patch-vesta.apache.org/179/console This message is automatically generated. ClassCastException in LedgerManagementProcessor --- Key: ZOOKEEPER-504 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-504 Project: Zookeeper Issue Type: Bug Components: contrib-bookkeeper Affects Versions: 3.2.0 Reporter: Utkarsh Srivastava Attachments: ZOOKEEPER-504.1.patch, ZOOKEEPER-504.patch, ZOOKEEPER-504.patch java.lang.ClassCastException: org.apache.bookkeeper.client.LedgerManagementProcessor$OpenLedgerOp cannot be cast to org.apache.bookkeeper.client.LedgerManagementProcessor$CloseLedgerOp at org.apache.bookkeeper.client.LedgerManagementProcessor.processResult(LedgerManagementProcessor.java:1083) This seems to be happening because its a nested switch case statement. And the OPEN: case, doesn't ever call a break. It only calls a break from the inner switch-case and hence falls through into the CLOSE: case. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
