[jira] Commented: (ZOOKEEPER-69) ZooKeeper logo
[ https://issues.apache.org/jira/browse/ZOOKEEPER-69?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12650449#action_12650449 ] Jeff Hammerbacher commented on ZOOKEEPER-69: http://www.99designs.com or http://logoworks.com will get you a well-designed logo for a good price (under $1K), if it's in the YHOO budget... ZooKeeper logo -- Key: ZOOKEEPER-69 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-69 Project: Zookeeper Issue Type: Wish Components: documentation Reporter: Flavio Paiva Junqueira Assignee: Benjamin Reed Priority: Minor Fix For: 3.1.0 Attachments: pbzk.gif, zk_logo_use.png, zk_logo_use2.png, zookeeper-sketch.jpg I think we need a cool logo for the project. The ones I've seen so far are a little lame, and that includes the one I've created for SourceForge. If anyone on this list has an idea or knows of anyone with some art skills, plese add a commento to this Jira. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-386) improve c and java cli shells
[ https://issues.apache.org/jira/browse/ZOOKEEPER-386?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12704465#action_12704465 ] Jeff Hammerbacher commented on ZOOKEEPER-386: - I'm +1 on JLine. It's not as nice as Python's readline support but we used it in Hive to similar effect, and having history + tab completion is critical for shell usability. improve c and java cli shells - Key: ZOOKEEPER-386 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-386 Project: Zookeeper Issue Type: Improvement Components: c client, java client Reporter: Patrick Hunt Priority: Minor Fix For: 3.2.0 copied from the following comments by Vegard https://issues.apache.org/jira/browse/ZOOKEEPER-364?focusedCommentId=12696002page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#action_12696002 Possible improvements: Default host list to localhost:2181 when not given. Don't print a ton of debug, it looks like both cli_mt and zkCli.sh does this. Make a simple ls that lists subnodes one line at a time and a simple cat that lists only the node content, simple put etc. Shell with gnu readline capabilities and tab completion on node names would be a big improvement of usability during testing and debugging. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-368) Observers
[ https://issues.apache.org/jira/browse/ZOOKEEPER-368?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12755382#action_12755382 ] Jeff Hammerbacher commented on ZOOKEEPER-368: - Hey, Now that 3.2.1 has gone out, does it make sense to review this patch? Thanks, Jeff Observers - Key: ZOOKEEPER-368 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-368 Project: Zookeeper Issue Type: New Feature Components: quorum Reporter: Flavio Paiva Junqueira Assignee: Henry Robinson Attachments: obs-refactor.patch, observer-refactor.patch, observers.patch, ZOOKEEPER-368.patch, ZOOKEEPER-368.patch, ZOOKEEPER-368.patch, ZOOKEEPER-368.patch, ZOOKEEPER-368.patch, ZOOKEEPER-368.patch Currently, all servers of an ensemble participate actively in reaching agreement on the order of ZooKeeper transactions. That is, all followers receive proposals, acknowledge them, and receive commit messages from the leader. A leader issues commit messages once it receives acknowledgments from a quorum of followers. For cross-colo operation, it would be useful to have a third role: observer. Using Paxos terminology, observers are similar to learners. An observer does not participate actively in the agreement step of the atomic broadcast protocol. Instead, it only commits proposals that have been accepted by some quorum of followers. One simple solution to implement observers is to have the leader forwarding commit messages not only to followers but also to observers, and have observers applying transactions according to the order followers agreed upon. In the current implementation of the protocol, however, commit messages do not carry their corresponding transaction payload because all servers different from the leader are followers and followers receive such a payload first through a proposal message. Just forwarding commit messages as they currently are to an observer consequently is not sufficient. We have a couple of options: 1- Include the transaction payload along in commit messages to observers; 2- Send proposals to observers as well. Number 2 is simpler to implement because it doesn't require changing the protocol implementation, but it increases traffic slightly. The performance impact due to such an increase might be insignificant, though. For scalability purposes, we may consider having followers also forwarding commit messages to observers. With this option, observers can connect to followers, and receive messages from followers. This choice is important to avoid increasing the load on the leader with the number of observers. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-368) Observers
[ https://issues.apache.org/jira/browse/ZOOKEEPER-368?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12755490#action_12755490 ] Jeff Hammerbacher commented on ZOOKEEPER-368: - Great! Thanks, Mahadev. Observers - Key: ZOOKEEPER-368 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-368 Project: Zookeeper Issue Type: New Feature Components: quorum Reporter: Flavio Paiva Junqueira Assignee: Henry Robinson Attachments: obs-refactor.patch, observer-refactor.patch, observers.patch, ZOOKEEPER-368.patch, ZOOKEEPER-368.patch, ZOOKEEPER-368.patch, ZOOKEEPER-368.patch, ZOOKEEPER-368.patch, ZOOKEEPER-368.patch Currently, all servers of an ensemble participate actively in reaching agreement on the order of ZooKeeper transactions. That is, all followers receive proposals, acknowledge them, and receive commit messages from the leader. A leader issues commit messages once it receives acknowledgments from a quorum of followers. For cross-colo operation, it would be useful to have a third role: observer. Using Paxos terminology, observers are similar to learners. An observer does not participate actively in the agreement step of the atomic broadcast protocol. Instead, it only commits proposals that have been accepted by some quorum of followers. One simple solution to implement observers is to have the leader forwarding commit messages not only to followers but also to observers, and have observers applying transactions according to the order followers agreed upon. In the current implementation of the protocol, however, commit messages do not carry their corresponding transaction payload because all servers different from the leader are followers and followers receive such a payload first through a proposal message. Just forwarding commit messages as they currently are to an observer consequently is not sufficient. We have a couple of options: 1- Include the transaction payload along in commit messages to observers; 2- Send proposals to observers as well. Number 2 is simpler to implement because it doesn't require changing the protocol implementation, but it increases traffic slightly. The performance impact due to such an increase might be insignificant, though. For scalability purposes, we may consider having followers also forwarding commit messages to observers. With this option, observers can connect to followers, and receive messages from followers. This choice is important to avoid increasing the load on the leader with the number of observers. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-661) Add Ruby bindings
[ https://issues.apache.org/jira/browse/ZOOKEEPER-661?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12836061#action_12836061 ] Jeff Hammerbacher commented on ZOOKEEPER-661: - How does this work compare to http://github.com/emaland/zookeeper_client/? Add Ruby bindings - Key: ZOOKEEPER-661 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-661 Project: Zookeeper Issue Type: New Feature Components: contrib-bindings Environment: MRI Ruby 1.9 JRuby 1.4 Reporter: Andrew Reynhout Priority: Minor Add Ruby bindings to the ZooKeeper distribution. Ruby presents special threading difficulties for asynchronous ZK calls (aget, watchers, etc). It looks like the simplest workaround is to patch the ZK C API. Proposed approach will be described in comment. Please use this ticket for discussion and suggestions. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-733) use netty to handle client connections
[ https://issues.apache.org/jira/browse/ZOOKEEPER-733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12893027#action_12893027 ] Jeff Hammerbacher commented on ZOOKEEPER-733: - Hey Ben, One motivation for the move to Netty was performance-related: bq. we would also like the engine to use multiple threads on machines with lots of cores. Did your benchmarks run on a machine with multiple cores? Any evidence of utilization of multiple cores would be of interest to me. Thanks, Jeff use netty to handle client connections -- Key: ZOOKEEPER-733 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-733 Project: Zookeeper Issue Type: Improvement Components: server Reporter: Benjamin Reed Assignee: Patrick Hunt Fix For: 3.4.0 Attachments: accessive.jar, flowctl.zip, moved.zip, QuorumTestFailed_sessionmoved_TRACE_LOG.txt.gz, ZOOKEEPER-733.patch, ZOOKEEPER-733.patch, ZOOKEEPER-733.patch, ZOOKEEPER-733.patch, ZOOKEEPER-733.patch, ZOOKEEPER-733.patch, ZOOKEEPER-733.patch, ZOOKEEPER-733.patch we currently have our own asynchronous NIO socket engine to be able to handle lots of clients with a single thread. over time the engine has become more complicated. we would also like the engine to use multiple threads on machines with lots of cores. plus, we would like to be able to support things like SSL. if we switch to netty, we can simplify our code and get the previously mentioned benefits. -- 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.
