I’ll take a look later and get back to you. I took a cursory look and it seems right. I too was wondering whether Curator should auto-start the watcher or not. I need to think about that some more. Maybe other committers have an idea as well.
On November 10, 2014 at 11:46:03 AM, Ioannis Canellos ([email protected]) wrote: Any thoughts on what I posted about the EnsemblerProvider / EnsembleTracker? On Mon, Nov 10, 2014 at 5:55 PM, Jordan Zimmerman <[email protected]> wrote: > So, it would get added to the Retry logic as another retry-able excetpion? > I’ll ask on the ZK list to make sure. > > > On November 10, 2014 at 6:35:07 AM, Ioannis Canellos ([email protected]) > wrote: > > From what I understand its not an indication of invalid config, its > rather an indication that things are not ready for the operation, as > it just indicates that the quorum of servers that are meant to be part > of the "new" ensemble are not yet synced with the leader (which is a > requirement). > > The description on the code explicitly tells that we should try again > when all servers are connected and synced, so it definitely sounds > like a retry-able one. > > > On Fri, Nov 7, 2014 at 8:04 PM, Jordan Zimmerman > <[email protected]> wrote: >> In the ZooKeeper meetup yesterday, Alex mentioned the exception >> NewConfigNoQuorum. I was a bit unclear on this. Is this thrown when the >> new >> config is invalid or is it a new kind of recoverable exception? If it’s >> recoverable, Curator will need to handle it I guess. >> >> -JZ >> >> >> On November 6, 2014 at 11:07:41 AM, Jordan Zimmerman >> ([email protected]) wrote: >> >> Please create PRs for these so that we can review. >> >> Thanks for the great start. >> >> -Jordan >> >> >> On November 6, 2014 at 10:45:53 AM, Ioannis Canellos ([email protected]) >> wrote: >> >> The branch CURATOR-3.0 has been created. If we agree that we want to >> rename it to 3.x we can do that. >> >> I also created and pushed a first draft of CURATOR-160. The commit >> adds builders and DSL on the CuratorFramework for the new config() and >> reconfig() methods of ZooKeeper. It also contains a unit test that >> tries out possible combinations. >> >> As a next step, I think that we should extend the existing DSL (which >> heavily uses strings following the ZooKeepers methods signatures) and >> provide methods with more meaningful signatures. If you lost me, here >> is an example of how it can be used. >> >> >> client.reconfig().join("server.4=someip:2888:3888;participant;2181").join("server.5=someotherip:2888:3888;participant;2181).forConfig(someVersion); >> >> >> It's somehow painful to remember the format of the string, so I think >> that we should provide an alternative for join that could look like: >> >> join(long id, String host, int clientPort, int peerPort, int >> electionPort, String type); >> >> Meanwhile I'll start looking at implementing an EnsembleProvider that >> will be reconfiguration aware, which is required to close the issue. >> >> >> >> On Thu, Nov 6, 2014 at 11:48 AM, Ioannis Canellos <[email protected]> >> wrote: >>> Agreed, though I would name the common branch 3.x (mostly to separate >>> it from the issue branches). >>> >>> >>> On Wed, Nov 5, 2014 at 5:54 PM, Jordan Zimmerman >>> <[email protected]> wrote: >>>> Also, I think we should still make separate branches for each feature >>>> but >>>> have a CURATOR-3.0 branch for managing the completed features. >>>> >>>> -JZ >>>> >>>> >>>> On November 5, 2014 at 9:52:16 AM, Ioannis Canellos ([email protected]) >>>> wrote: >>>> >>>> So I picked up CURATOR-160 from the list. >>>> >>>> What I have in mind is creating a 3.x branch (as I think that we >>>> generally agree on this) and then add the required DSL on the curator >>>> framework to support the reconfig and getconfig methods. >>>> >>>> As a next step we need to decide how we will handle internally the >>>> reconfiguration of zookeeper. Personally I like the idea of an >>>> EnsembleProvider implementation. >>>> >>>> Thoughts? >>>> >>>> On Sat, Nov 1, 2014 at 6:29 PM, Jordan Zimmerman >>>> <[email protected]> wrote: >>>>> FYI >>>>> >>>>> I’ve created a container Jira for ZK 3.5.0 subtasks: >>>>> >>>>> https://issues.apache.org/jira/browse/CURATOR-159 >>>>> >>>>> >>>>> On November 1, 2014 at 11:25:35 AM, Jordan Zimmerman >>>>> ([email protected]) wrote: >>>>> >>>>> I think we should identify the tasks, create Jiras, etc. Then figure >>>>> out >>>>> the >>>>> best path from there. So, in that spirit, let’s begin. >>>>> >>>>> Major new features in 3.5.x that Curator needs to handle in some way: >>>>> >>>>> * Dynamic Reconfig >>>>> * Remove Watches >>>>> * Local Session >>>>> >>>>> Here is the current 3.5.x release notes page. Is there anything else >>>>> from >>>>> here that Curator should handle? >>>>> >>>>> >>>>> >>>>> >>>>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310801&version=12316644 >>>>> >>>>> >>>>> -Jordan >>>>> >>>>> >>>>> On November 1, 2014 at 11:21:35 AM, Ioannis Canellos >>>>> ([email protected]) >>>>> wrote: >>>>> >>>>> Is anyone working on this? I could spend some time on zk 3.5.0. >>>>> >>>>> -- >>>>> Ioannis Canellos >>>>> >>>>> Blog: http://iocanel.blogspot.com >>>>> Twitter: iocanel >>>> >>>> >>>> >>>> -- >>>> Ioannis Canellos >>>> >>>> Blog: http://iocanel.blogspot.com >>>> Twitter: iocanel >>> >>> >>> >>> -- >>> Ioannis Canellos >>> >>> Blog: http://iocanel.blogspot.com >>> Twitter: iocanel >> >> >> >> -- >> Ioannis Canellos >> >> Blog: http://iocanel.blogspot.com >> Twitter: iocanel > > > > -- > Ioannis Canellos > > Blog: http://iocanel.blogspot.com > Twitter: iocanel -- Ioannis Canellos Blog: http://iocanel.blogspot.com Twitter: iocanel
