Re: Restarting discussion on ZooKeeper as a TLP
Excited to see ZooKeeper graduate to TLP. On Wed, Oct 13, 2010 at 2:10 PM, Patrick Hunt wrote: > In March of this year we discussed a request from the Apache Board, and > Hadoop PMC, that we become a TLP rather than a subproject of Hadoop: > > Original discussion > http://markmail.org/thread/42cobkpzlgotcbin > > I originally voted against this move, my primary concern being that we were > not "ready" to move to tlp status given our small contributor base and > limited contributor diversity. However I'd now like to revisit that > discussion/decision. Since that time the team has been working hard to > attract new contributors, and we've seen significant new contributions come > in. There has also been feedback from board/pmc addressing many of these > concerns (both on the list and in private). I am now less concerned about > this issue and don't see it as a blocker for us to move to TLP status. > > A second concern was that by becoming a TLP the project would lose it's > connection with Hadoop, a big source of new users for us. I've been assured > (and you can see with the other projects that have moved to tlp status; > pig/hive/hbase/etc...) that this connection will be maintained. The Hadoop > ZooKeeper tab for example will redirect to our new homepage. > > Other Apache members also pointed out to me that we are essentially > operating as a TLP within the Hadoop PMC. Most of the other PMC members > have > little or no experience with ZooKeeper and this makes it difficult for them > to monitor and advise us. By moving to TLP status we'll be able to govern > ourselves and better set our direction. > > I believe we are ready to become a TLP. Please respond to this email with > your thoughts and any issues. I will call a vote in a few days, once > discussion settles. > > Regards, > > Patrick >
[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.
[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-tabpanel&focusedCommentId=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.
Re: A deficiency? You can only add children to persistent nodes
Hey Ben,
Perhaps you should open a JIRA for further discussion?
Thanks,
Jeff
On Mon, Mar 22, 2010 at 7:42 PM, Benjamin Reed wrote:
> let me put out an idea that we have kicked around for a while: ephemeral
> containers. the idea is that the znode disappears if it doesn't have
> children. you would create the znode with create("/path", data, acl,
> EPHEMERAL_CONTAINER) this would result in the creation two znodes: /path and
> /path/child. (we have to create it with a child otherwise it immediately
> disappears.)
>
> i think this mechanism would address your need in a way that is easy to
> implement and use. it would also allow you to do a cool barrier
> implementation!
>
> ben
>
>
> On 03/22/2010 10:37 AM, Patrick Hunt wrote:
>
>> Dominic Williams wrote:
>>
>>
>>> What I'd suggest might work:
>>> - when the session that created the parent ends, ownership of the parent
>>> could either be transferred to the owner/session that created the oldest
>>> child, or instead ownership could be transferred to some kind of nominal
>>> system session (which would delete the parent once the last ephemeral
>>> child
>>> disappeared)
>>>
>>>
>> There may be some issues with idempotency here, also it could require
>> extensive locking which drives up operation latencies (essentially
>> "recursive delete"). It sounds possible, but someone would have to take
>> a closer look as to the technical challenges involved.
>>
>>
>> Our general philosophy is to keep things as simple as possible wrt api,
>> semantics, implementation, etc... Distributed communication is hard and
>> while we handle a lot of the issues for you it's still complex.
>> Following our philosophy generally makes the easy things simple and the
>> hard things possible, additionally it reduces the number of bugs that we
>> have in the implementation itself (both user and service code).
>>
>> I don't wish to discourage you as much as provide insight/background
>> into some of our decisions.
>>
>> Regards,
>>
>> Patrick
>>
>>
>>
>>> On 22 March 2010 16:44, Patrick Hunt wrote:
>>>
>>>
>>>
Dominic Williams wrote:
> 1/ If a node crashes or something else goes wrong, you leave behind
> persistent nodes. Over time these will grow and grow, rather like the
> old
> tmp folders used to fill with files under Windows
>
>
>
That's true. One either needs to use ephemerals or use persistent and
have
a "garbage collector" (implicit or explicit gc). In most cases it's
preferable to use the ephemeral.
2/ Persistent nodes = nasty scalability *bottleneck* because you're
> actually
> having to write to disk somewhere.
>
>
>
This is not actually how ZK works. All znodes regardless of
persistent/ephemeral are written to disk persistently. Ephemeral nodes
are
tied to the session that created them. As long as the session is alive
the
ephemeral node is alive. Sessions themselves are persistently/reliably
stored by the ZK cluster. This allows the shutdown of the entire cluster
and
restart it, all sessions/ephemerals will be maintained. Sessions can
move
from server to server (if say network connectivity to server A fails, or
server A itself fails then the client will move to server B). The
session
and all ephemerals are maintained (well, as long as the client moves
withing
the expiration timeout value).
To avoid this I'm actually thinking of writing locking system where you
> work
> out the existing chain not by enumerating sequential children, but by
> looking at the contents of each temporary lock node to see what it is
> waiting on. But... that's quite horrible. Was wondering whether there
> is
> some technical reason why you ephemeral nodes can't have children??
>
>
>
There are a few cases to think about.
1) obviously ephemeral nodes can't have persistent children, this just
doesn't make sense
2) ephemeral nodes have an owner - the session that created them. so it
would also not make sense (in my mind at least) to have an ephemeral
/foo
with another ephemeral /foo/bar with a different owner.
3) so you are left with "ephemerals can be a child of an ephemeral with
the
same owner".
4) there are also issues of order. in particular what is the "deletion
order" depth first or breadth first, etc...
I believe the answer so far has been "we don't do this because it's
fairly
complicated and we haven't seen any use cases that require it." In the
cases
I've seen so far there was either a misunderstanding of how zk worked,
or a
simpler way available.
Does that make sense? Thoughts?
Patrick
>>>
>>>
>>
>
[jira] Commented: (ZOOKEEPER-661) Add Ruby bindings
[ https://issues.apache.org/jira/browse/ZOOKEEPER-661?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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.
Re: Ruby client binding for ZooKeeper now available.
Are there plans to integrate this work with the Apache project? https://issues.apache.org/jira/browse/ZOOKEEPER-661. On Fri, Feb 19, 2010 at 10:23 AM, Patrick Hunt wrote: > Sorry if this is a dup for those of you following me on twitter ( > http://twitter.com/phunt) but I wanted to let you know that twitter (the > company) has contributed a Ruby client binding for ZooKeeper. You can learn > more about the gem here: http://bit.ly/b9VB6k > > Regards, > > Patrick >
Re: Ruby ZooKeeper bindings
Hey, Given that Hadoop is moving over to Avro RPC, and Java, C, and Python bindings for Avro should be usable by the end of January with the 1.3 release (fingers crossed), would it make sense to spend a bit of energy on Ruby bindings for Avro as well? If you're interested, I'd be happy to put you in touch with some folks from Twitter working on the Ruby Avro bindings. Either way, excited to see the work! Later, Jeff On Tue, Dec 22, 2009 at 10:21 AM, wrote: > Sounds good. I'll open a Jira ticket when the patches are ready for > review and discussion. I agree that maintaining the code in multiple > repositories is something to avoid if at all possible. > > Thanks, > Andrew > > > > On Mon, Dec 21, 2009 at 04:31:33PM -0800, Mahadev Konar wrote: > > Hi andrew, > > If the changes to zookeeper source tree are minor and do not change the > > functionality of the system/api's/data structures, I think its better to > > file it as a patch to the main zookeeper source tree. Its would be > > unadvisable to maintain 2 source tree's for the c code or even a patch in > > the ruby bindings that applies to the c source tree at runtime > compilation. > > I would suggest that you can open a jira and propose the changes that you > > intend to make on the zookeeper source tree and the reasoning behind it. > We > > can discuss any alternatives if we need to on the jira. > > > > Thanks > > mahadev > > -- > reynh...@quesera.com >
[jira] Commented: (ZOOKEEPER-368) Observers
[ https://issues.apache.org/jira/browse/ZOOKEEPER-368?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12776774#action_12776774 ] Jeff Hammerbacher commented on ZOOKEEPER-368: - Flavio, This patch was submitted five months ago. Blocking its submission to trunk, which is not intended to be a stable release, so that another bug can be fixed seems imprudent. I hope you'll consider pushing the patch through and fixing the FLE issue separately. Mahadev seems to agree with this philosophy. Henry doesn't work full time on Zookeeper and we'd really like to get this JIRA in so that work can be done in smaller chunks moving forward. 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 > sync benchmark.png, observers.patch, ZOOKEEPER-368.patch, > ZOOKEEPER-368.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-tabpanel&focusedCommentId=12776569#action_12776569 ] Jeff Hammerbacher commented on ZOOKEEPER-368: - bq. So we can block the Observers patch on this feature, or we can get a reduced Observers patch in (and prevent another cycle of refactoring when trunk gets updated and the patch no longer applies). Either is good; but I'm probably in favour of getting the patch in now and updating once the ResponderThread JIRA gets closed. The change to re-enable Observers for all election types is pretty trivial. I agree with Henry. Let's get this patch in and handle the unusual case of TCP-only FLE in a separate patch for 578. bq. This should therefore be a separate JIRA (I'm trying to avoid having several issues fixed by this patch). Also strongly agree. Get the patch in and handle the hardcoded code removal this patch turned up in 577. > 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 > sync benchmark.png, observers.patch, ZOOKEEPER-368.patch, > ZOOKEEPER-368.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-tabpanel&focusedCommentId=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-368) Observers
[ https://issues.apache.org/jira/browse/ZOOKEEPER-368?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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-386) improve c and java cli shells
[ https://issues.apache.org/jira/browse/ZOOKEEPER-386?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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=12696002&page=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-69) ZooKeeper logo
[ https://issues.apache.org/jira/browse/ZOOKEEPER-69?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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.
