Alexander Shraer 2012-10-10, 18:52
Michi Mutsuzaki 2012-10-10, 21:35
Alexander Shraer 2012-10-10, 21:48
Michi Mutsuzaki 2012-10-10, 22:23
Marshall McMullen 2012-10-11, 03:46
The incremental mode is easier to use and has better guarantees. To use the non-incremental mode you need to know what the current config is and modify it. Suppose that you and I are doing this concurrently trying to make two different configuration changes. What will happen is that one of the changes (the one that gets to the leader first) will be silently overwritten by the other one. If you condition on the current config version (this is supported) the second reconfig will fail and you'll have to repeat the steps (read config, make your change and submit).
With incremental reconfig you dont need to know the config. You just say you want to add A, I say I want to remove B, and both changes will be applied to the current config.
On Oct 10, 2012, at 20:46, Marshall McMullen <[EMAIL PROTECTED]> wrote:
> Alex, one thing I've been meaning to ask you regarding ZK-107 is why there exists a separate incremental and non-incremental reconfig interface. It seems things would be simpler on the clients if they only supported the non-incremental reconfig and let the server sort out which servers are joining and which are leaving...
> Can you explain a bit why both interfaces are required? How is the code path in the server different depending on which interface you use?
> On Wed, Oct 10, 2012 at 3:48 PM, Alexander Shraer <[EMAIL PROTECTED]> wrote:
>> great! thanks guys, your help is really appreciated!!
>> please use the latest ZK-107 patch as I've changed some parts of the C
>> implementation recently. Don't hesitate
>> to ask me for any clarifications about the new APIs. For reference you
>> can also take a look on the new Java tests in that patch,
>> although I think that they cover much more than necessary for the C tests.
>> Michi, actually there is a related patch
>> (https://issues.apache.org/jira/browse/ZOOKEEPER-1355) that needs a
>> Flavio reviewed the Java part of it, and I fixed the patch according
>> to his comments, and then Marshall added a C
>> implementation that wasn't reviewed yet. I don't feel confident enough
>> in the C client implementation to review it.
>> If you can review it, please use Marshall's latest patch on this Jira.
>> If you like using the reviewboard I can update it with latest code.
>> On Wed, Oct 10, 2012 at 2:35 PM, Michi Mutsuzaki <[EMAIL PROTECTED]> wrote:
>> > I'm available as well for reviewing the code, writing test, or
>> > whatever is necessary to get this feature out.
>> > Thanks!
>> > --Michi
>> > On Wed, Oct 10, 2012 at 2:24 PM, Marshall McMullen
>> > <[EMAIL PROTECTED]> wrote:
>> >> Hey Alex, I am definitely (still) interested in helping out with this.
>> >> Unfortunately things have been super busy for me for the last few
>> >> weeks in my day job and it's required a lot of late nights and after
>> >> hours to finish.
>> >> I'm wrapping that up now, so I intend to have some free time over
>> >> the next couple weeks where I'll be able to contribute to this very
>> >> worthy feature.
>> >> --Marshall
>> >> ---------- Forwarded message ----------
>> >> From: Alexander Shraer <[EMAIL PROTECTED]>
>> >> Date: Wed, Oct 10, 2012 at 12:52 PM
>> >> Subject: C client & reconfiguration
>> >> To: [EMAIL PROTECTED]
>> >> Hi All,
>> >> If you're using (or familiar with) the ZooKeeper C client and would
>> >> like to help out with ZooKeeper 107, we still need a couple of
>> >> basic C tests for it. There are currently plenty of Java client and
>> >> server tests, including all kinds of failure scenarios,
>> >> so the C client tests should really just test the basic C reconfiguration
>> >> API.
>> >> Thanks,
>> >> Alex
Marshall McMullen 2012-10-11, 04:25