[jira] Commented: (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:comment-tabpanelfocusedCommentId=12904571#action_12904571
]
Andrei Savu commented on ZOOKEEPER-853:
---
Thanks Henry.
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.
[jira] Commented: (ZOOKEEPER-858) Zookeeper appears as QuorumPeerMain in jps output, which is not very user-friendly
[
https://issues.apache.org/jira/browse/ZOOKEEPER-858?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12904587#action_12904587
]
Andrei Savu commented on ZOOKEEPER-858:
---
{{jps -l}} looks user-friendly enough for me:
\\ \\
{noformat}
9355 org.apache.zookeeper.server.quorum.QuorumPeerMain
9472 sun.tools.jps.Jps
9354 org.apache.zookeeper.server.quorum.QuorumPeerMain
9358 org.apache.zookeeper.server.quorum.QuorumPeerMain
9357 org.apache.zookeeper.server.quorum.QuorumPeerMain
9356 org.apache.zookeeper.server.quorum.QuorumPeerMain
{noformat}
Renaming {{QuorumPeerMain}} to something like {{ZooKeeperQuorumPeerMain}}
sounds like too much.
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.
Build failed in Hudson: ZooKeeper-trunk #920
See https://hudson.apache.org/hudson/job/ZooKeeper-trunk/920/changes Changes: [henry] ZOOKEEPER-853: Make zookeeper.is_unrecoverable return True or False in zkpython -- [...truncated 167935 lines...] [junit] 2010-08-31 10:50:45,403 [myid:] - INFO [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:11237:nioservercnxnfact...@196] - Accepted socket connection from /127.0.0.1:41932 [junit] 2010-08-31 10:50:45,404 [myid:] - INFO [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:11237:nioserverc...@791] - Processing stat command from /127.0.0.1:41932 [junit] 2010-08-31 10:50:45,404 [myid:] - INFO [Thread-281:nioservercnxn$statcomm...@645] - Stat command output [junit] 2010-08-31 10:50:45,405 [myid:] - INFO [Thread-281:nioserverc...@967] - Closed socket connection for client /127.0.0.1:41932 (no session established for client) [junit] 2010-08-31 10:50:45,405 [myid:] - INFO [main:quorumb...@195] - 127.0.0.1:11237 is accepting client connections [junit] 2010-08-31 10:50:45,405 [myid:] - INFO [main:clientb...@225] - connecting to 127.0.0.1 11238 [junit] 2010-08-31 10:50:45,405 [myid:] - INFO [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:11238:nioservercnxnfact...@196] - Accepted socket connection from /127.0.0.1:54837 [junit] 2010-08-31 10:50:45,406 [myid:] - INFO [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:11238:nioserverc...@791] - Processing stat command from /127.0.0.1:54837 [junit] 2010-08-31 10:50:45,406 [myid:] - INFO [Thread-282:nioservercnxn$statcomm...@645] - Stat command output [junit] 2010-08-31 10:50:45,407 [myid:] - INFO [Thread-282:nioserverc...@967] - Closed socket connection for client /127.0.0.1:54837 (no session established for client) [junit] 2010-08-31 10:50:45,407 [myid:] - INFO [main:quorumb...@195] - 127.0.0.1:11238 is accepting client connections [junit] 2010-08-31 10:50:45,407 [myid:] - INFO [main:clientb...@225] - connecting to 127.0.0.1 11239 [junit] 2010-08-31 10:50:45,407 [myid:] - INFO [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:11239:nioservercnxnfact...@196] - Accepted socket connection from /127.0.0.1:43752 [junit] 2010-08-31 10:50:45,408 [myid:] - INFO [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:11239:nioserverc...@791] - Processing stat command from /127.0.0.1:43752 [junit] 2010-08-31 10:50:45,408 [myid:] - INFO [Thread-283:nioserverc...@967] - Closed socket connection for client /127.0.0.1:43752 (no session established for client) [junit] 2010-08-31 10:50:45,659 [myid:] - INFO [main:clientb...@225] - connecting to 127.0.0.1 11239 [junit] 2010-08-31 10:50:45,659 [myid:] - INFO [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:11239:nioservercnxnfact...@196] - Accepted socket connection from /127.0.0.1:43753 [junit] 2010-08-31 10:50:45,659 [myid:] - INFO [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:11239:nioserverc...@791] - Processing stat command from /127.0.0.1:43753 [junit] 2010-08-31 10:50:45,660 [myid:] - INFO [Thread-284:nioserverc...@967] - Closed socket connection for client /127.0.0.1:43753 (no session established for client) [junit] 2010-08-31 10:50:45,910 [myid:] - INFO [main:clientb...@225] - connecting to 127.0.0.1 11239 [junit] 2010-08-31 10:50:45,911 [myid:] - INFO [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:11239:nioservercnxnfact...@196] - Accepted socket connection from /127.0.0.1:43754 [junit] 2010-08-31 10:50:45,911 [myid:] - INFO [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:11239:nioserverc...@791] - Processing stat command from /127.0.0.1:43754 [junit] 2010-08-31 10:50:45,911 [myid:] - INFO [Thread-285:nioserverc...@967] - Closed socket connection for client /127.0.0.1:43754 (no session established for client) [junit] 2010-08-31 10:50:46,162 [myid:] - INFO [main:clientb...@225] - connecting to 127.0.0.1 11239 [junit] 2010-08-31 10:50:46,162 [myid:] - INFO [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:11239:nioservercnxnfact...@196] - Accepted socket connection from /127.0.0.1:43755 [junit] 2010-08-31 10:50:46,162 [myid:] - INFO [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:11239:nioserverc...@791] - Processing stat command from /127.0.0.1:43755 [junit] 2010-08-31 10:50:46,163 [myid:] - INFO [Thread-286:nioserverc...@967] - Closed socket connection for client /127.0.0.1:43755 (no session established for client) [junit] 2010-08-31 10:50:46,413 [myid:] - INFO [main:clientb...@225] - connecting to 127.0.0.1 11239 [junit] 2010-08-31 10:50:46,413 [myid:] - INFO [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:11239:nioservercnxnfact...@196] - Accepted socket connection from /127.0.0.1:43756 [junit] 2010-08-31 10:50:46,414 [myid:] - INFO [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:11239:nioserverc...@791] - Processing stat command from /127.0.0.1:43756 [junit] 2010-08-31 10:50:46,414 [myid:] - INFO [Thread-287:nioservercnxn$statcomm...@645] - Stat command output [junit] 2010-08-31 10:50:46,414 [myid:] - INFO
[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=12904620#action_12904620 ] Flavio Junqueira commented on ZOOKEEPER-702: +1 to changing the API to use either ping or heartbeat only. I prefer ping because it is shorter. 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] Updated: (ZOOKEEPER-823) update ZooKeeper java client to optionally use Netty for connections
[ https://issues.apache.org/jira/browse/ZOOKEEPER-823?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Koch updated ZOOKEEPER-823: -- Attachment: ZOOKEEPER-823.patch This is a refactoring of phunt's patch to separate the socket specific code into subclasses of ClientCnxnSocket and make ClientCnxn concrete again. IMHO this makes the code much more comprehendable. I'm sorry, that eclipse made the patch a little larger then necessary. I've turned the auto-reformatting off now, but I don't know any easy way to undo the formatting changes. update ZooKeeper java client to optionally use Netty for connections Key: ZOOKEEPER-823 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-823 Project: Zookeeper Issue Type: New Feature Components: java client Reporter: Patrick Hunt Assignee: Patrick Hunt Fix For: 3.4.0 Attachments: ZOOKEEPER-823.patch, ZOOKEEPER-823.patch, ZOOKEEPER-823.patch This jira will port the client side connection code to use netty rather than direct nio. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-823) update ZooKeeper java client to optionally use Netty for connections
[ https://issues.apache.org/jira/browse/ZOOKEEPER-823?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Koch updated ZOOKEEPER-823: -- Attachment: ZOOKEEPER-823.patch update ZooKeeper java client to optionally use Netty for connections Key: ZOOKEEPER-823 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-823 Project: Zookeeper Issue Type: New Feature Components: java client Reporter: Patrick Hunt Assignee: Patrick Hunt Fix For: 3.4.0 Attachments: ZOOKEEPER-823.patch, ZOOKEEPER-823.patch, ZOOKEEPER-823.patch This jira will port the client side connection code to use netty rather than direct nio. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-823) update ZooKeeper java client to optionally use Netty for connections
[ https://issues.apache.org/jira/browse/ZOOKEEPER-823?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Koch updated ZOOKEEPER-823: -- Attachment: (was: ZOOKEEPER-823.patch) update ZooKeeper java client to optionally use Netty for connections Key: ZOOKEEPER-823 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-823 Project: Zookeeper Issue Type: New Feature Components: java client Reporter: Patrick Hunt Assignee: Patrick Hunt Fix For: 3.4.0 Attachments: ZOOKEEPER-823.patch, ZOOKEEPER-823.patch This jira will port the client side connection code to use netty rather than direct nio. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: windows port of C API
Ben Collins ben.coll...@... writes: 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, is it possible to get that port? We'd like to try it out in our environment. Single-threaded is ok in the first step. Of course we'll contribute the enhancements if we can make some. Best regards Jan
RE: windows port of C API
I would be very interested to see any work already done and provide feedback, we need such a port and were planning on writing one ourselves. C -Original Message- From: Ben Collins [mailto:ben.coll...@foundationdb.com] Sent: Monday, August 30, 2010 5:01 PM To: zookeeper-dev@hadoop.apache.org Subject: 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] Commented: (ZOOKEEPER-822) Leader election taking a long time to complete
[ https://issues.apache.org/jira/browse/ZOOKEEPER-822?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12904684#action_12904684 ] Flavio Junqueira commented on ZOOKEEPER-822: Hi VIshal, Good catches: 1- It sounds right that blocking the connection establishment might increase the time to election unnecessarily when the other party is not up. Here is my interpretation. If the machine is up but the the zk server is not running, then we simply get a connection failure and move on. The same doesn't happen when the the machine is down, since we need to wait for the connection establishment to time out; 2- It sounds right that a connection can be dropped erroneously due to a race, but I don't see in which case it can cause the election time to increase substantially, unless the race is triggered multiple times in a row. A server will try to connect upon every new notification, and a server only calls SendWorker.finish() in receiveNotification if it has a higher identifier. In this case, it creates a new connection immediately after, so it would need a previous connection being dropped right before to have the case you're describing; 3- Servers with higher identifiers decline connection requests from servers with lower identifiers; it is part of the protocol. Is this what you're referring to? Leader election taking a long time to complete --- Key: ZOOKEEPER-822 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-822 Project: Zookeeper Issue Type: Bug Components: quorum Affects Versions: 3.3.0 Reporter: Vishal K Priority: Blocker Attachments: 822.tar.gz, rhel.tar.gz, test_zookeeper_1.log, test_zookeeper_2.log, zk_leader_election.tar.gz, zookeeper-3.4.0.tar.gz Created a 3 node cluster. 1 Fail the ZK leader 2. Let leader election finish. Restart the leader and let it join the 3. Repeat After a few rounds leader election takes anywhere 25- 60 seconds to finish. Note- we didn't have any ZK clients and no new znodes were created. zoo.cfg is shown below: #Mon Jul 19 12:15:10 UTC 2010 server.1=192.168.4.12\:2888\:3888 server.0=192.168.4.11\:2888\:3888 clientPort=2181 dataDir=/var/zookeeper syncLimit=2 server.2=192.168.4.13\:2888\:3888 initLimit=5 tickTime=2000 I have attached logs from two nodes that took a long time to form the cluster after failing the leader. The leader was down anyways so logs from that node shouldn't matter. Look for START HERE. Logs after that point should be of our interest. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: windows port of C API
Hi Ben, that's great!. There has been some interest in this, however I'm not aware that anyone has done a port. Here's how to contrib: http://wiki.apache.org/hadoop/ZooKeeper/HowToContribute basically you would create a JIRA and attach your patch against latest trunk svn. The committers will review and provide feedback. It would be great to not have to manage multiple build systems for the c code. Should we switch to something like cmake instead of autotools? Or will that work for you (win/cygwin/unix based build I mean). Patrick On Mon, Aug 30, 2010 at 2:00 PM, Ben Collins ben.coll...@foundationdb.comwrote: 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] Assigned: (ZOOKEEPER-804) c unit tests failing due to assertion cptr failed
[ https://issues.apache.org/jira/browse/ZOOKEEPER-804?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michi Mutsuzaki reassigned ZOOKEEPER-804: - Assignee: Michi Mutsuzaki (was: Mahadev konar) c unit tests failing due to assertion cptr failed --- Key: ZOOKEEPER-804 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-804 Project: Zookeeper Issue Type: Bug Components: c client Affects Versions: 3.4.0 Environment: gcc 4.4.3, ubuntu lucid lynx, dual core laptop (intel) Reporter: Patrick Hunt Assignee: Michi Mutsuzaki Priority: Critical Fix For: 3.3.2, 3.4.0 I'm seeing this frequently: [exec] Zookeeper_simpleSystem::testPing : elapsed 18006 : OK [exec] Zookeeper_simpleSystem::testAcl : elapsed 1022 : OK [exec] Zookeeper_simpleSystem::testChroot : elapsed 3145 : OK [exec] Zookeeper_simpleSystem::testAuth ZooKeeper server started : elapsed 25687 : OK [exec] zktest-mt: /home/phunt/dev/workspace/gitzk/src/c/src/zookeeper.c:1952: zookeeper_process: Assertion `cptr' failed. [exec] make: *** [run-check] Aborted [exec] Zookeeper_simpleSystem::testHangingClient Mahadev can you take a look? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: windows port of C API
Hi Ben, that's great!. There has been some interest in this, however I'm not aware that anyone has done a port. Here's how to contrib: http://wiki.apache.org/hadoop/ZooKeeper/HowToContribute basically you would create a JIRA and attach your patch against latest trunk svn. The committers will review and provide feedback. It would be great to not have to manage multiple build systems for the c code. Should we switch to something like cmake instead of autotools? Or will that work for you (win/cygwin/unix based build I mean). Patrick On Mon, Aug 30, 2010 at 2:00 PM, Ben Collins ben.coll...@foundationdb.comwrote: 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
Re: windows port of C API
I agree that avoiding the multiple build systems would be nice. Unfortunately, though, windows is an animal unto itself. I would be hesitant to change the whole build system over to cmake just for the ideal situation that there be one build system for all platforms. I have seen projects that maintain the win32 build separate from the *nix builds, and this does not seem to be too onerous. I'm flexible, but will probably in the end use the same tools to build as I do now. One remaining critical issue is the zookeeper_close() call while the client is in the CONNECTED state. Even in the single-threaded setup this call blocks when connected instead of using zookeeper_interest() and a callback, as seems appropriate. The current code can cause an infinite loop. For this port to be serious, we would need this cleaned up. On Tue, Aug 31, 2010 at 1:09 PM, Patrick Hunt phu...@gmail.com wrote: Hi Ben, that's great!. There has been some interest in this, however I'm not aware that anyone has done a port. Here's how to contrib: http://wiki.apache.org/hadoop/ZooKeeper/HowToContribute basically you would create a JIRA and attach your patch against latest trunk svn. The committers will review and provide feedback. It would be great to not have to manage multiple build systems for the c code. Should we switch to something like cmake instead of autotools? Or will that work for you (win/cygwin/unix based build I mean). Patrick On Mon, Aug 30, 2010 at 2:00 PM, Ben Collins ben.coll...@foundationdb.com wrote: 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 -- Ben
Re: windows port of C API
Sounds reasonable. If we really want to be serious about it we should update hudson (or add buildbot) to build/test on cygwin/windows in addition to our current ubuntu build. But we can do it by hand to start with. Patrick On Tue, Aug 31, 2010 at 11:06 AM, Ben Collins ben.coll...@foundationdb.comwrote: I agree that avoiding the multiple build systems would be nice. Unfortunately, though, windows is an animal unto itself. I would be hesitant to change the whole build system over to cmake just for the ideal situation that there be one build system for all platforms. I have seen projects that maintain the win32 build separate from the *nix builds, and this does not seem to be too onerous. I'm flexible, but will probably in the end use the same tools to build as I do now. One remaining critical issue is the zookeeper_close() call while the client is in the CONNECTED state. Even in the single-threaded setup this call blocks when connected instead of using zookeeper_interest() and a callback, as seems appropriate. The current code can cause an infinite loop. For this port to be serious, we would need this cleaned up. On Tue, Aug 31, 2010 at 1:09 PM, Patrick Hunt phu...@gmail.com wrote: Hi Ben, that's great!. There has been some interest in this, however I'm not aware that anyone has done a port. Here's how to contrib: http://wiki.apache.org/hadoop/ZooKeeper/HowToContribute basically you would create a JIRA and attach your patch against latest trunk svn. The committers will review and provide feedback. It would be great to not have to manage multiple build systems for the c code. Should we switch to something like cmake instead of autotools? Or will that work for you (win/cygwin/unix based build I mean). Patrick On Mon, Aug 30, 2010 at 2:00 PM, Ben Collins ben.coll...@foundationdb.com wrote: 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 -- Ben
[jira] Updated: (ZOOKEEPER-823) update ZooKeeper java client to optionally use Netty for connections
[ https://issues.apache.org/jira/browse/ZOOKEEPER-823?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Hunt updated ZOOKEEPER-823: --- Status: Open (was: Patch Available) update ZooKeeper java client to optionally use Netty for connections Key: ZOOKEEPER-823 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-823 Project: Zookeeper Issue Type: New Feature Components: java client Reporter: Patrick Hunt Assignee: Patrick Hunt Fix For: 3.4.0 Attachments: ZOOKEEPER-823.patch, ZOOKEEPER-823.patch, ZOOKEEPER-823.patch This jira will port the client side connection code to use netty rather than direct nio. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (ZOOKEEPER-859) Native Windows version of C client
Native Windows version of C client -- Key: ZOOKEEPER-859 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-859 Project: Zookeeper Issue Type: New Feature Components: c client Affects Versions: 3.3.1 Environment: Windows 7, 64-bit Reporter: Ben Collins Use windows sockets and the win32 API for implementing the c client. This would be only useful for the single-threaded model, where the IO waiting is taken care of in the calling code. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-859) Native Windows version of C client
[ https://issues.apache.org/jira/browse/ZOOKEEPER-859?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ben Collins updated ZOOKEEPER-859: -- Attachment: zk-win32-2010-08-31.patch config.h win32port.c The basic files for a new win32 port of the C API Native Windows version of C client -- Key: ZOOKEEPER-859 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-859 Project: Zookeeper Issue Type: New Feature Components: c client Affects Versions: 3.3.1 Environment: Windows 7, 64-bit Reporter: Ben Collins Attachments: config.h, win32port.c, zk-win32-2010-08-31.patch Use windows sockets and the win32 API for implementing the c client. This would be only useful for the single-threaded model, where the IO waiting is taken care of in the calling code. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-859) Native Windows version of C client
[ https://issues.apache.org/jira/browse/ZOOKEEPER-859?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Hunt updated ZOOKEEPER-859: --- Assignee: Ben Collins Fix Version/s: 3.4.0 Native Windows version of C client -- Key: ZOOKEEPER-859 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-859 Project: Zookeeper Issue Type: New Feature Components: c client Affects Versions: 3.3.1 Environment: Windows 7, 64-bit Reporter: Ben Collins Assignee: Ben Collins Fix For: 3.4.0 Attachments: config.h, win32port.c, zk-win32-2010-08-31.patch Use windows sockets and the win32 API for implementing the c client. This would be only useful for the single-threaded model, where the IO waiting is taken care of in the calling code. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: High WTF count in ZooKeeper client code
There isnt any documentation on the interface tagging other than the running comments. I will try to get hold of one of the hadoop folks to get me a dump of the info and will create a jira! Thanks mahadev On 8/11/10 9:56 AM, Patrick Hunt ph...@apache.org wrote: wrt defining interface stability we should adopt something like hadoop is now doing: https://issues.apache.org/jira/browse/HADOOP-5073 Mahadev, do you know if this is documented somewhere? final documentation, rather than the running commentary thats on this jira? We could adopt something similar/same. Can you create a jira for that? Patrick On 08/11/2010 08:23 AM, Thomas Koch wrote: Hallo Mahadev, thank you for your nice answer. Yes, we'll of cause preserve compatibility. Otherwise there is no chance to get accepted. I assume the following things must keep their interfaces: ZooKeeper (It'll call the new interface in the background), ASyncCallback, Watcher We may want to change: ClientCnxn (faktor out some things, remove dep on ZooKeeper) I think other classes should not be involved at all in our issues. My collegue Patrick was so kind to fill the jira issues. Best regards, Thomas Mahadev Konar: Also, I am assuming you have backwards compatability in mind when you suggest these changes right? The interfaces of zookeeper client should not be changing as part of this, though the recursive delete hasn't been introduced yet (its only available in 3.4, so we can move it out into a helper class). Thanks mahadev On 8/11/10 7:40 AM, Mahadev Konarmaha...@yahoo-inc.com wrote: HI Thomas, I read through the list of issues you posted, most of them seem reasonable to fix. The one's you have mentioned below might take quite a bit of time to fix and again a lot of testing! (just a warning :)). It would be great if you'd want to clean this up for 3.4. Please go ahead and file a jira. These improvements would be good to have in the zookeeper java client. For deleteRecursive, I definitely agree that it should be a helper class. I don't believe it should be in the direct zookeeper api! Thanks mahadev On 8/11/10 2:45 AM, Thomas Kochtho...@koch.ro wrote: Hi, I started yesterday to work on my idea of an alternative ZooKeeper client interface.[1] Instead of methods on a ZooKeeper class, a user should instantiate an Operation (Create, Delete, ...) and forward it to an Executor which handles session loss errors and alikes. By doing that, I got shocked by the sheer number of WTF issues I found. I'm sorry for ranting now, but it gets quicker to the poing. - Hostlist as string The hostlist is parsed in the ctor of ClientCnxn. This violates the rule of not doing (too much) work in a ctor. Instead the ClientCnxn should receive an object of class HostSet. HostSet could then be instantiated e.g. with a comma separated string. - cyclic dependency ClientCnxn, ZooKeeper ZooKeeper instantiates ClientCnxn in its ctor with this and therefor builds a cyclic dependency graph between both objects. This means, you can't have the one without the other. So why did you bother do make them to separate classes in the first place? ClientCnxn accesses ZooKeeper.state. State should rather be a property of ClientCnxn. And ClientCnxn accesses zooKeeper.get???Watches() in its method primeConnection(). I've not yet checked, how this dependency should be resolved better. - Chroot is an attribute of ClientCnxn I'd like to have one process that uses ZooKeeper for different things (managing a list of work, locking some unrelated locks elsewhere). So I've components that do this work inside the same process. These components should get the same zookeeper-client reference chroot'ed for their needs. So it'd be much better, if the ClientCnxn would not care about the chroot. - deleteRecursive does not belong to the other methods DeleteRecursive has been committed to trunk already as a method to the zookeeper class. So in the API it has the same level as the atomic operations create, delete, getData, setData, etc. The user must get the false impression, that deleteRecursive is also an atomic operation. It would be better to have deleteRecursive in some helper class but not that deep in zookeeper's core code. Maybe I'd like to have another policy on how to react if deleteRecursive fails in the middle of its work? - massive code duplication in zookeeper class Each operation calls validatePath, handles the chroot, calls ClientCnxn and checks the return header for error. I'd like to address this with the operation classes: Each operation should receive a prechecked Path object. Calling ClientCnxn and error checking is not (or only partly) the concern of the operation but of an executor like class. - stat is returned by parameter Since one can return only one value in java it's the only choice to do so. Still it feels more like C then like Java. However with operator classes one could simply
[jira] Assigned: (ZOOKEEPER-856) Connection imbalance leads to overloaded ZK instances
[ https://issues.apache.org/jira/browse/ZOOKEEPER-856?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mahadev konar reassigned ZOOKEEPER-856: --- Assignee: Mahadev konar Connection imbalance leads to overloaded ZK instances - Key: ZOOKEEPER-856 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-856 Project: Zookeeper Issue Type: Bug Reporter: Travis Crawford Assignee: Mahadev konar Fix For: 3.4.0 Attachments: zk_open_file_descriptor_count_members.gif, zk_open_file_descriptor_count_total.gif We've experienced a number of issues lately where ruok requests would take upwards of 10 seconds to return, and ZooKeeper instances were extremely sluggish. The sluggish instance requires a restart to make it responsive again. I believe the issue is connections are very imbalanced, leading to certain instances having many thousands of connections, while other instances are largely idle. A potential solution is periodically disconnecting/reconnecting to balance connections over time; this seems fine because sessions should not be affected, and therefore ephemaral nodes and watches should not be affected. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-844) handle auth failure in java client
[
https://issues.apache.org/jira/browse/ZOOKEEPER-844?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Giridharan Kesavan updated ZOOKEEPER-844:
-
Status: Patch Available (was: Open)
handle auth failure in java client
--
Key: ZOOKEEPER-844
URL: https://issues.apache.org/jira/browse/ZOOKEEPER-844
Project: Zookeeper
Issue Type: Improvement
Components: java client
Affects Versions: 3.3.1
Reporter: Camille Fournier
Assignee: Camille Fournier
Fix For: 3.4.0
Attachments: ZOOKEEPER-844.patch
ClientCnxn.java currently has the following code:
if (replyHdr.getXid() == -4) {
// -2 is the xid for AuthPacket
// TODO: process AuthPacket here
if (LOG.isDebugEnabled()) {
LOG.debug(Got auth sessionid:0x
+ Long.toHexString(sessionId));
}
return;
}
Auth failures appear to cause the server to disconnect but the client never
gets a proper state change or notification that auth has failed, which makes
handling this scenario very difficult as it causes the client to go into a
loop of sending bad auth, getting disconnected, trying to reconnect, sending
bad auth again, over and over.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-844) handle auth failure in java client
[
https://issues.apache.org/jira/browse/ZOOKEEPER-844?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Giridharan Kesavan updated ZOOKEEPER-844:
-
Status: Open (was: Patch Available)
submitting to hudson
handle auth failure in java client
--
Key: ZOOKEEPER-844
URL: https://issues.apache.org/jira/browse/ZOOKEEPER-844
Project: Zookeeper
Issue Type: Improvement
Components: java client
Affects Versions: 3.3.1
Reporter: Camille Fournier
Assignee: Camille Fournier
Fix For: 3.4.0
Attachments: ZOOKEEPER-844.patch
ClientCnxn.java currently has the following code:
if (replyHdr.getXid() == -4) {
// -2 is the xid for AuthPacket
// TODO: process AuthPacket here
if (LOG.isDebugEnabled()) {
LOG.debug(Got auth sessionid:0x
+ Long.toHexString(sessionId));
}
return;
}
Auth failures appear to cause the server to disconnect but the client never
gets a proper state change or notification that auth has failed, which makes
handling this scenario very difficult as it causes the client to go into a
loop of sending bad auth, getting disconnected, trying to reconnect, sending
bad auth again, over and over.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Zoosh!
I created a wrapper package for Java zookeeper shell. Unlike C version, it supports command history and tab completion. $ yinst install zoosh -br test $ zoosh localhost:2181 http://dist.corp.yahoo.com/by-package/zoosh/ --Michi
