> On Feb. 3, 2015, 8:56 p.m., Vinod Kone wrote: > > src/authentication/cram_md5/authenticator.hpp, lines 517-526 > > <https://reviews.apache.org/r/27760/diff/12-13/?file=834177#file834177line517> > > > > Instead of terminate() (or making it public) why not have an onDiscard > > handler on the future returned at #508 that erases the pid?
We were not holding on onto the inner future (authenticate) and hence I had no way to do that. Now I have solved this by wrapping the authenticate future with another one that becomes ready only if we had a completely succefull authentication (that is both, future is ready __AND__ Option<string> contains a principal). > On Feb. 3, 2015, 8:56 p.m., Vinod Kone wrote: > > src/authentication/authenticator.hpp, lines 76-77 > > <https://reviews.apache.org/r/27760/diff/12-13/?file=834176#file834176line76> > > > > Not looking at the implementation, this seems to be a weird interface > > method. if authenticate() returns a future why do the caller need an > > explicit terminate() to terminate the authentication? would be easy if he > > can just 'discard' the future which will cause termination. You are completely right. It makes much more sense that way. - Till ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/27760/#review70822 ----------------------------------------------------------- On Feb. 13, 2015, 3:20 p.m., Till Toenshoff wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/27760/ > ----------------------------------------------------------- > > (Updated Feb. 13, 2015, 3:20 p.m.) > > > Review request for mesos, Adam B, Kapil Arya, Niklas Nielsen, and Vinod Kone. > > > Bugs: MESOS-2050 > https://issues.apache.org/jira/browse/MESOS-2050 > > > Repository: mesos > > > Description > ------- > > The initial design and implementation of the authenticator module interface > caused issues and was not optimal for heavy lifting setup of external > dependencies. By introducing a two fold design, this has been decoupled from > the authentication message processing. The new design also gets us back on > track to the goal of makeing SASL a soft dependency of mesos. > > > Diffs > ----- > > include/mesos/authentication/authenticator.hpp f66217a > src/authentication/cram_md5/authenticator.hpp 7578ea1 > src/authentication/cram_md5/auxprop.hpp d036b11 > src/authentication/cram_md5/auxprop.cpp 5ff9755 > src/master/master.hpp 6a39df0 > src/master/master.cpp f10a3cf > src/tests/cram_md5_authentication_tests.cpp dd102dc > > Diff: https://reviews.apache.org/r/27760/diff/ > > > Testing > ------- > > make check > > > Thanks, > > Till Toenshoff > >
