Build failed in Hudson: ZooKeeper-trunk #919
See https://hudson.apache.org/hudson/job/ZooKeeper-trunk/919/ -- [...truncated 166038 lines...] [junit] 2010-08-30 10:51:22,646 [myid:] - INFO [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:11237:nioservercnxnfact...@196] - Accepted socket connection from /127.0.0.1:47470 [junit] 2010-08-30 10:51:22,646 [myid:] - INFO [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:11237:nioserverc...@791] - Processing stat command from /127.0.0.1:47470 [junit] 2010-08-30 10:51:22,647 [myid:] - INFO [Thread-318:nioservercnxn$statcomm...@645] - Stat command output [junit] 2010-08-30 10:51:22,647 [myid:] - INFO [Thread-318:nioserverc...@967] - Closed socket connection for client /127.0.0.1:47470 (no session established for client) [junit] 2010-08-30 10:51:22,648 [myid:] - INFO [main:quorumb...@195] - 127.0.0.1:11237 is accepting client connections [junit] 2010-08-30 10:51:22,648 [myid:] - INFO [main:clientb...@225] - connecting to 127.0.0.1 11238 [junit] 2010-08-30 10:51:22,648 [myid:] - INFO [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:11238:nioservercnxnfact...@196] - Accepted socket connection from /127.0.0.1:40335 [junit] 2010-08-30 10:51:22,649 [myid:] - INFO [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:11238:nioserverc...@791] - Processing stat command from /127.0.0.1:40335 [junit] 2010-08-30 10:51:22,649 [myid:] - INFO [Thread-319:nioservercnxn$statcomm...@645] - Stat command output [junit] 2010-08-30 10:51:22,650 [myid:] - INFO [Thread-319:nioserverc...@967] - Closed socket connection for client /127.0.0.1:40335 (no session established for client) [junit] 2010-08-30 10:51:22,650 [myid:] - INFO [main:quorumb...@195] - 127.0.0.1:11238 is accepting client connections [junit] 2010-08-30 10:51:22,650 [myid:] - INFO [main:clientb...@225] - connecting to 127.0.0.1 11239 [junit] 2010-08-30 10:51:22,651 [myid:] - INFO [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:11239:nioservercnxnfact...@196] - Accepted socket connection from /127.0.0.1:42162 [junit] 2010-08-30 10:51:22,651 [myid:] - INFO [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:11239:nioserverc...@791] - Processing stat command from /127.0.0.1:42162 [junit] 2010-08-30 10:51:22,651 [myid:] - INFO [Thread-320:nioserverc...@967] - Closed socket connection for client /127.0.0.1:42162 (no session established for client) [junit] 2010-08-30 10:51:22,902 [myid:] - INFO [main:clientb...@225] - connecting to 127.0.0.1 11239 [junit] 2010-08-30 10:51:22,902 [myid:] - INFO [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:11239:nioservercnxnfact...@196] - Accepted socket connection from /127.0.0.1:42163 [junit] 2010-08-30 10:51:22,902 [myid:] - INFO [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:11239:nioserverc...@791] - Processing stat command from /127.0.0.1:42163 [junit] 2010-08-30 10:51:22,903 [myid:] - INFO [Thread-321:nioserverc...@967] - Closed socket connection for client /127.0.0.1:42163 (no session established for client) [junit] 2010-08-30 10:51:23,153 [myid:] - INFO [main:clientb...@225] - connecting to 127.0.0.1 11239 [junit] 2010-08-30 10:51:23,153 [myid:] - INFO [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:11239:nioservercnxnfact...@196] - Accepted socket connection from /127.0.0.1:42164 [junit] 2010-08-30 10:51:23,154 [myid:] - INFO [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:11239:nioserverc...@791] - Processing stat command from /127.0.0.1:42164 [junit] 2010-08-30 10:51:23,154 [myid:] - INFO [Thread-322:nioserverc...@967] - Closed socket connection for client /127.0.0.1:42164 (no session established for client) [junit] 2010-08-30 10:51:23,404 [myid:] - INFO [main:clientb...@225] - connecting to 127.0.0.1 11239 [junit] 2010-08-30 10:51:23,405 [myid:] - INFO [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:11239:nioservercnxnfact...@196] - Accepted socket connection from /127.0.0.1:42165 [junit] 2010-08-30 10:51:23,405 [myid:] - INFO [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:11239:nioserverc...@791] - Processing stat command from /127.0.0.1:42165 [junit] 2010-08-30 10:51:23,405 [myid:] - INFO [Thread-323:nioserverc...@967] - Closed socket connection for client /127.0.0.1:42165 (no session established for client) [junit] 2010-08-30 10:51:23,656 [myid:] - INFO [main:clientb...@225] - connecting to 127.0.0.1 11239 [junit] 2010-08-30 10:51:23,656 [myid:] - INFO [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:11239:nioservercnxnfact...@196] - Accepted socket connection from /127.0.0.1:42166 [junit] 2010-08-30 10:51:23,656 [myid:] - INFO [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:11239:nioserverc...@791] - Processing stat command from /127.0.0.1:42166 [junit] 2010-08-30 10:51:23,657 [myid:] - INFO [Thread-324:nioservercnxn$statcomm...@645] - Stat command output [junit] 2010-08-30 10:51:23,657 [myid:] - INFO [Thread-324:nioserverc...@967] - Closed socket connection for client /127.0.0.1:42166 (no session established for client)
[jira] Updated: (ZOOKEEPER-702) GSoC 2010: Failure Detector Model
[ https://issues.apache.org/jira/browse/ZOOKEEPER-702?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Abmar Barros updated ZOOKEEPER-702: --- Attachment: ZOOKEEPER-702.patch I this patch I have addressed all the issues Ivan and Flavio raised, but the reflection code on the FaiilureDetectorFactory, in which I am working. What do you think is the most user-friendly way of configuring the failure detector? (using reflection on the FailureDetectorFactory). Should we require the fully classified class name in the fd.classname option and the parameters should be like fd.param1, fd.param2...? In this sense, should we force the failure detectors classes to have methods like setParam1(String param1), setParam2(String param2)...? GSoC 2010: Failure Detector Model - Key: ZOOKEEPER-702 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-702 Project: Zookeeper Issue Type: Wish Reporter: Henry Robinson Assignee: Abmar Barros Attachments: bertier-pseudo.txt, bertier-pseudo.txt, chen-pseudo.txt, chen-pseudo.txt, phiaccrual-pseudo.txt, phiaccrual-pseudo.txt, ZOOKEEPER-702-code.patch, ZOOKEEPER-702-doc.patch, ZOOKEEPER-702.patch, ZOOKEEPER-702.patch, ZOOKEEPER-702.patch, ZOOKEEPER-702.patch, ZOOKEEPER-702.patch, ZOOKEEPER-702.patch, ZOOKEEPER-702.patch, ZOOKEEPER-702.patch, ZOOKEEPER-702.patch, ZOOKEEPER-702.patch, ZOOKEEPER-702.patch Failure Detector Module Possible Mentor Henry Robinson (henry at apache dot org) Requirements Java, some distributed systems knowledge, comfort implementing distributed systems protocols Description ZooKeeper servers detects the failure of other servers and clients by counting the number of 'ticks' for which it doesn't get a heartbeat from other machines. This is the 'timeout' method of failure detection and works very well; however it is possible that it is too aggressive and not easily tuned for some more unusual ZooKeeper installations (such as in a wide-area network, or even in a mobile ad-hoc network). This project would abstract the notion of failure detection to a dedicated Java module, and implement several failure detectors to compare and contrast their appropriateness for ZooKeeper. For example, Apache Cassandra uses a phi-accrual failure detector (http://ddsg.jaist.ac.jp/pub/HDY+04.pdf) which is much more tunable and has some very interesting properties. This is a great project if you are interested in distributed algorithms, or want to help re-factor some of ZooKeeper's internal code. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-702) GSoC 2010: Failure Detector Model
[ https://issues.apache.org/jira/browse/ZOOKEEPER-702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12904247#action_12904247 ] Ivan Kelly commented on ZOOKEEPER-702: -- I think putting it under the fd.classname would be most accessible for users. For example, fd.myfailuredetector = com.softwaresoft.zk.myFailureDetector fd.myfailuredetector.blahblah = foobar fd.myfailuredetector.myoption = barfoo etc... Then when the factory tries to instantiate a myfailuredetector and it sees that myfailuredetector isn't a known type it should look up fd. + myfailuredetector in properties, and instantiate the class with fdOptions as a parameter. Let the implementation take care of which options it wants to read from fdOptions. GSoC 2010: Failure Detector Model - Key: ZOOKEEPER-702 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-702 Project: Zookeeper Issue Type: Wish Reporter: Henry Robinson Assignee: Abmar Barros Attachments: bertier-pseudo.txt, bertier-pseudo.txt, chen-pseudo.txt, chen-pseudo.txt, phiaccrual-pseudo.txt, phiaccrual-pseudo.txt, ZOOKEEPER-702-code.patch, ZOOKEEPER-702-doc.patch, ZOOKEEPER-702.patch, ZOOKEEPER-702.patch, ZOOKEEPER-702.patch, ZOOKEEPER-702.patch, ZOOKEEPER-702.patch, ZOOKEEPER-702.patch, ZOOKEEPER-702.patch, ZOOKEEPER-702.patch, ZOOKEEPER-702.patch, ZOOKEEPER-702.patch, ZOOKEEPER-702.patch Failure Detector Module Possible Mentor Henry Robinson (henry at apache dot org) Requirements Java, some distributed systems knowledge, comfort implementing distributed systems protocols Description ZooKeeper servers detects the failure of other servers and clients by counting the number of 'ticks' for which it doesn't get a heartbeat from other machines. This is the 'timeout' method of failure detection and works very well; however it is possible that it is too aggressive and not easily tuned for some more unusual ZooKeeper installations (such as in a wide-area network, or even in a mobile ad-hoc network). This project would abstract the notion of failure detection to a dedicated Java module, and implement several failure detectors to compare and contrast their appropriateness for ZooKeeper. For example, Apache Cassandra uses a phi-accrual failure detector (http://ddsg.jaist.ac.jp/pub/HDY+04.pdf) which is much more tunable and has some very interesting properties. This is a great project if you are interested in distributed algorithms, or want to help re-factor some of ZooKeeper's internal code. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-702) GSoC 2010: Failure Detector Model
[ https://issues.apache.org/jira/browse/ZOOKEEPER-702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12904251#action_12904251 ] Ivan Kelly commented on ZOOKEEPER-702: -- One more comment on the API. Ping and heartbeat seem to be used interchangeably though it's my understanding that these are fundamentally the same thing. GSoC 2010: Failure Detector Model - Key: ZOOKEEPER-702 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-702 Project: Zookeeper Issue Type: Wish Reporter: Henry Robinson Assignee: Abmar Barros Attachments: bertier-pseudo.txt, bertier-pseudo.txt, chen-pseudo.txt, chen-pseudo.txt, phiaccrual-pseudo.txt, phiaccrual-pseudo.txt, ZOOKEEPER-702-code.patch, ZOOKEEPER-702-doc.patch, ZOOKEEPER-702.patch, ZOOKEEPER-702.patch, ZOOKEEPER-702.patch, ZOOKEEPER-702.patch, ZOOKEEPER-702.patch, ZOOKEEPER-702.patch, ZOOKEEPER-702.patch, ZOOKEEPER-702.patch, ZOOKEEPER-702.patch, ZOOKEEPER-702.patch, ZOOKEEPER-702.patch Failure Detector Module Possible Mentor Henry Robinson (henry at apache dot org) Requirements Java, some distributed systems knowledge, comfort implementing distributed systems protocols Description ZooKeeper servers detects the failure of other servers and clients by counting the number of 'ticks' for which it doesn't get a heartbeat from other machines. This is the 'timeout' method of failure detection and works very well; however it is possible that it is too aggressive and not easily tuned for some more unusual ZooKeeper installations (such as in a wide-area network, or even in a mobile ad-hoc network). This project would abstract the notion of failure detection to a dedicated Java module, and implement several failure detectors to compare and contrast their appropriateness for ZooKeeper. For example, Apache Cassandra uses a phi-accrual failure detector (http://ddsg.jaist.ac.jp/pub/HDY+04.pdf) which is much more tunable and has some very interesting properties. This is a great project if you are interested in distributed algorithms, or want to help re-factor some of ZooKeeper's internal code. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
windows port of C API
I have a working win32 port of the C API, not depending on Cygwin, that supports the single-threaded model of network interaction. It compiles in Visual Studio 2010 and works on 64 bit Windows 7. There are know issues, and it is in it's initial stages; but it has been successfully used against the java server. I am happy to provide patches, but would like any pointers to efforts already undertaken in this area, or folks to communicate with about this. Thanks, -- Ben
[jira] Updated: (ZOOKEEPER-853) Make zookeeper.is_unrecoverable return True or False and not an integer
[
https://issues.apache.org/jira/browse/ZOOKEEPER-853?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henry Robinson updated ZOOKEEPER-853:
-
Status: Resolved (was: Patch Available)
Resolution: Fixed
I just committed this (to trunk) - thanks Andrei!
Make zookeeper.is_unrecoverable return True or False and not an integer
---
Key: ZOOKEEPER-853
URL: https://issues.apache.org/jira/browse/ZOOKEEPER-853
Project: Zookeeper
Issue Type: Improvement
Components: contrib-bindings
Reporter: Andrei Savu
Assignee: Andrei Savu
Priority: Minor
Fix For: 3.4.0
Attachments: ZOOKEEPER-853.patch, ZOOKEEPER-853.patch
This is a patch that fixes a TODO from the python zookeeper extension, it
makes {{zookeeper.is_unrecoverable}} return {{True}} or {{False}} and not an
integer.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: WIP: introduce ClientCnxnSocket classes for nicer netty integration
On 08/22/2010 06:19 AM, Thomas Koch wrote: If you could help me to move the logic from xyz() back in the run() method with fitting calls to the socket() class, then I might be done. I'm a bit puzzled because in NIO there's first a selector.select(to) and then doWrites(), while in Netty there's first doWrites() and then outgoingQueue.wait(to). The control logic is indeed swapped here for nio/netty. In the NIO case we have set flags that specify whether we are interested in performing writes or not (nio will return once a socket we've expressed interest in is available to write, it could return immediately). In netty we have a queue of packets and write them to the channel (under which I'm assuming netty does similar to what we are doing in our nio code). The packet generating code will notify outgoing queue when new packets are added to the queue. In the NIO case we are essentially saying wait to write until something can be written, while in the netty case we are write everything and then wait until more packets are available to write. That help? Patrick
[jira] Created: (ZOOKEEPER-857) clarify client vs. server view of session expiration event
clarify client vs. server view of session expiration event -- Key: ZOOKEEPER-857 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-857 Project: Zookeeper Issue Type: Bug Components: documentation Reporter: qing yan Per mailing list discussion: quote the client only finds out about session expiration events when the client reconnects to the cluster. if zk tells a client that its session is expired, the ephemerals that correspond to that session will already be cleaned up. - deletion of an ephemeral file due to loss of client connection will occur after the client gets a connection loss - deletion of an ephemeral file will precede delivery of a session expiration event to the owner /quote So session expirations means two things here : server view(ephemeral clean up) client view(event delivery) , there are no guarantee how long it will take in between, correct? I guess the confusion rises from the documention which doesn't distinguish these two concepts, e.g. in the javadoc http://hadoop.apache.org/zookeeper/docs/r3.3.1/api/index.html An ephemeral node will be removed by the ZooKeeper automatically when the session associated with the creation of the node expires. It is actually refering to the server view not the client view. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (ZOOKEEPER-858) Zookeeper appears as QuorumPeerMain in jps output, which is not very user-friendly
Zookeeper appears as QuorumPeerMain in jps output, which is not very user-friendly -- Key: ZOOKEEPER-858 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-858 Project: Zookeeper Issue Type: Improvement Reporter: Jeff Hammerbacher As noted by Jordan Sissel on Twitter: http://twitter.com/jordansissel/status/22570450969 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
