> On Nov. 9, 2013, 1:21 a.m., Ben Mahler wrote: > > src/zookeeper/contender.cpp, line 130 > > <https://reviews.apache.org/r/13086/diff/12/?file=378503#file378503line130> > > > > If candidacy is not ready, it's still possible that contend() has been > > called (if the group->join is still in progress). This doesn't match the > > documentation in contender.hpp: > > > > // Returns true if successfully withdrawn from the contest (either > > // while contending or has already contended and is watching for > > // membership loss). > > // A false return value implies that there was no valid group > > // membership to cancel, which may be a result of a race to cancel > > // an expired membership. > > // A failed future is returned if the method is called before > > // contend() or more than once. > > process::Future<bool> withdraw(); > > > > In the case where contend() has been called, and withdraw() was called > > prior to us joining the Group, we'll be returning a failed Future?
When !candidacy.isReady(), can we just defer() back into withdraw without changing anything else? > On Nov. 9, 2013, 1:21 a.m., Ben Mahler wrote: > > src/zookeeper/contender.hpp, lines 43-51 > > <https://reviews.apache.org/r/13086/diff/12/?file=378502#file378502line43> > > > > Is there a difference between withdraw() and calling discard() on one > > of the Futures returned by contend? > > > > The implementation of LeaderContender appears to do different things > > depending on whether the contend was discarded or withdraw() was called. Is > > it possible to simplify this and have both operations go through the same > > code paths? > > > > It seems like withdraw can handle all possible valid withdrawal states > > and the onDiscarded callbacks can call withdraw instead of fail? > > > > Or is there a reason not to withdraw when the client discards the > > future? On discarded, we should either do nothing or the right thing (withdraw). How about we do nothing, like Group, and just increase the robustness of withdraw to handle the race I mentioned below? - Ben ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/13086/#review28588 ----------------------------------------------------------- On Nov. 5, 2013, 10:17 p.m., Jiang Yan Xu wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/13086/ > ----------------------------------------------------------- > > (Updated Nov. 5, 2013, 10:17 p.m.) > > > Review request for mesos, Benjamin Hindman, Ben Mahler, and Vinod Kone. > > > Bugs: MESOS-496 > https://issues.apache.org/jira/browse/MESOS-496 > > > Repository: mesos-git > > > Description > ------- > > See summary. > > > Diffs > ----- > > src/Makefile.am 9780d07a23ca196c541a44a85499c2f44a574b9c > src/tests/zookeeper_test_server.cpp > 0b22f319a53d08f9fe15c97c634b03358f40ba7e > src/tests/zookeeper_tests.cpp 16c5fb7daaf684ece5542b42dd9e9ec66f4a41ce > src/zookeeper/contender.hpp PRE-CREATION > src/zookeeper/contender.cpp PRE-CREATION > src/zookeeper/detector.hpp PRE-CREATION > src/zookeeper/detector.cpp PRE-CREATION > > Diff: https://reviews.apache.org/r/13086/diff/ > > > Testing > ------- > > make check 100 times. > > > Thanks, > > Jiang Yan Xu > >
