Build failed in Hudson: ZooKeeper-trunk #818
See http://hudson.zones.apache.org/hudson/job/ZooKeeper-trunk/818/ -- [...truncated 129695 lines...] [junit] 2010-05-09 10:45:10,096 - INFO [main:follo...@166] - shutdown called [junit] java.lang.Exception: shutdown Follower [junit] at org.apache.zookeeper.server.quorum.Follower.shutdown(Follower.java:166) [junit] at org.apache.zookeeper.server.quorum.QuorumPeer.shutdown(QuorumPeer.java:689) [junit] at org.apache.zookeeper.test.QuorumBase.shutdown(QuorumBase.java:293) [junit] at org.apache.zookeeper.test.ZkDatabaseCorruptionTest.testCorruption(ZkDatabaseCorruptionTest.java:127) [junit] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [junit] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [junit] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [junit] at java.lang.reflect.Method.invoke(Method.java:597) [junit] at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44) [junit] at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15) [junit] at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41) [junit] at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20) [junit] at org.apache.zookeeper.JUnit4ZKTestRunner$LoggedInvokeMethod.evaluate(JUnit4ZKTestRunner.java:51) [junit] at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28) [junit] at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:31) [junit] at org.junit.rules.TestWatchman$1.evaluate(TestWatchman.java:48) [junit] at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:76) [junit] at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50) [junit] at org.junit.runners.ParentRunner$3.run(ParentRunner.java:193) [junit] at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:52) [junit] at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:191) [junit] at org.junit.runners.ParentRunner.access$000(ParentRunner.java:42) [junit] at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:184) [junit] at org.junit.runners.ParentRunner.run(ParentRunner.java:236) [junit] at junit.framework.JUnit4TestAdapter.run(JUnit4TestAdapter.java:39) [junit] at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.run(JUnitTestRunner.java:420) [junit] at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.launch(JUnitTestRunner.java:911) [junit] at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.main(JUnitTestRunner.java:768) [junit] 2010-05-09 10:45:10,097 - INFO [main:finalrequestproces...@378] - shutdown of request processor complete [junit] 2010-05-09 10:45:10,097 - INFO [CommitProcessor:3:commitproces...@148] - CommitProcessor exited loop! [junit] 2010-05-09 10:45:10,097 - INFO [FollowerRequestProcessor:3:followerrequestproces...@93] - FollowerRequestProcessor exited loop! [junit] 2010-05-09 10:45:10,097 - INFO [SyncThread:3:syncrequestproces...@151] - SyncRequestProcessor exited! [junit] 2010-05-09 10:45:10,105 - INFO [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:11225:nioservercnxn$fact...@277] - NIOServerCnxn factory exited run method [junit] 2010-05-09 10:45:10,105 - ERROR [Thread-175:quorumcnxmanager$liste...@453] - Exception while listening [junit] java.nio.channels.AsynchronousCloseException [junit] at java.nio.channels.spi.AbstractInterruptibleChannel.end(AbstractInterruptibleChannel.java:185) [junit] at sun.nio.ch.ServerSocketChannelImpl.accept(ServerSocketChannelImpl.java:152) [junit] at org.apache.zookeeper.server.quorum.QuorumCnxManager$Listener.run(QuorumCnxManager.java:441) [junit] 2010-05-09 10:45:10,106 - INFO [main:quorumb...@296] - Shutting down leader election QuorumPeer:/0:0:0:0:0:0:0:0:11225 [junit] 2010-05-09 10:45:10,106 - INFO [main:quorumb...@301] - Waiting for QuorumPeer:/0:0:0:0:0:0:0:0:11225 to exit thread [junit] 2010-05-09 10:45:10,106 - INFO [Thread-175:quorumcnxmanager$liste...@457] - Leaving listener [junit] 2010-05-09 10:45:10,106 - WARN [Thread-194:quorumcnxmanager$recvwor...@658] - Connection broken: [junit] java.io.IOException: Channel eof [junit] at org.apache.zookeeper.server.quorum.QuorumCnxManager$RecvWorker.run(QuorumCnxManager.java:630) [junit] 2010-05-09 10:45:10,105 - WARN [Thread-182:quorumcnxmanager$sendwor...@581] - Interrupted while waiting for message on queue [junit] java.lang.InterruptedException [junit] at
[jira] Commented: (ZOOKEEPER-756) some cleanup and improvements for zooinspector
[ https://issues.apache.org/jira/browse/ZOOKEEPER-756?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12865630#action_12865630 ] Colin Goodheart-Smithe commented on ZOOKEEPER-756: -- I am having so technology issues and am without a development PC at the moment. I won't be able to look at this task for at least a couple of weeks while I sort out a new Development PC. If this issue is urgent i suggest it is assigned to someone else. If not i will endeavour to fix it when i have a new system up and running some cleanup and improvements for zooinspector -- Key: ZOOKEEPER-756 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-756 Project: Zookeeper Issue Type: Improvement Components: contrib Affects Versions: 3.3.0 Reporter: Thomas Koch Assignee: Colin Goodheart-Smithe Copied from the already closed ZOOKEEPER-678: * specify the exact URL, where the icons are from. It's best to include the link also in the NOTICE.txt file. It seems, that zooinspector finds it's icons only if the icons folder is in the current path. But when I install zooinspector as part of the Zookeeper Debian package, I want to be able to call it regardless of the current path. Could you use getRessources or something so that I can point to the icons location from the wrapper shell script? Can I place the zooinspector config files in /etc/zookeeper/zooinspector/ ? Could I give zooinspector a property to point to the config file location? There are several places, where viewers is missspelled as Veiwers. Please do a case insensitive search for veiw to correct these. Even the config file defaultNodeVeiwers.cfg is missspelled like this. This has the potential to confuse the hell out of people when debugging something! -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-679) Offers a node design for interacting with the Java Zookeeper client.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12865639#action_12865639 ] Henry Robinson commented on ZOOKEEPER-679: -- Hi Aaron - The great thing about open source, and the relatively permissive Apache license in particular, is that Chris is free to copy any and all of ZK into github and continue with a development process that he finds more agreeable. It is completely kosher to do this. As Chris says, you are welcome to contribute, fork or ignore it. As far as I am concerned, contrib is an excellent place to put projects that directly add more functionality to their parent project (the language bindings and this patch are good examples), but not a great place to store standalone projects that simply leverage the parent (an example might be a DNS server, written in ZooKeeper). This is a needfully vague distinction, and others will have different opinions. I do not know specifically to what Chris is referring when he talks about an 'onerous' patch process, but I speculate he might mean that the role of 'committer' - someone who is gating the submission of patches - makes it harder to get your patches available for others to use quickly. Of course there are also benefits of this approach, such as a ready collection of experienced users on hand to offer advice and the relatively high standard for patches to be accepted to trunk arguably improves code quality. What's great is the two development styles are not mutually exclusive, and can, ideally, benefit from each other. If you are having difficulties with, or are frustrated by, the patch submission process here, ask for help. The community here is very happy to help, and we'll do what we can to address pain points. As for this patch, I'm happy it's going into contrib - users sometimes find ZooKeeper difficult to program to, and examples and new abstractions are always welcome. Keeping this patch in the main repository means that newcomers to ZooKeeper will find it more easily. Thanks for the contribution! Henry Offers a node design for interacting with the Java Zookeeper client. Key: ZOOKEEPER-679 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-679 Project: Zookeeper Issue Type: New Feature Components: contrib, java client, tests Reporter: Aaron Crow Assignee: Aaron Crow Fix For: 3.4.0 Attachments: ZOOKEEPER-679.patch, ZOOKEEPER-679.patch, ZOOKEEPER-679.patch, ZOOKEEPER-679.patch Following up on my conversations with Patrick and Mahadev (http://n2.nabble.com/Might-I-contribute-a-Node-design-for-the-Java-API-td4567695.html#a4567695). This patch includes the implementation as well as unit tests. The first unit test gives a simple high level demo of using the node API. The current implementation is simple and is only what I need withe current project I am working on. However, I am very open to any and all suggestions for improvement. This is a proposal to support a simplified node (or File) like API into a Zookeeper tree, by wrapping the Zookeeper Java client. It is similar to Java's File API design. Although, I'm trying to make it easier in a few spots. For example, deleting a Node recursively is done by default. I also lean toward resolving Exceptions under the hood when it seems appropriate. For example, if you ask a Node if it exists, and its parent doesn't even exist, you just get a false back (rather than a nasty Exception). As for watches and ephemeral nodes, my current work does not need these things so I currently have no handling of them. But if potential users of the Node a.k.a. File design want these things, I'd be open to supporting them as reasonable. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
