----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/21464/#review43041 -----------------------------------------------------------
src/slave/slave.cpp <https://reviews.apache.org/r/21464/#comment77035> Technically register_backoff_jitter is allowed to be equal to REGISTER_RETRY_INTERVAL_MAX, right? In that case the upper bound of the random wait value is always REGISTER_RETRY_INTERVAL_MAX, which is not surprising to the user. src/tests/slave_recovery_tests.cpp <https://reviews.apache.org/r/21464/#comment77049> Are ReregisterSlaveMessage -> SlaveReregisteredMessage here and below necessary for the backoff change? - Jiang Yan Xu On May 14, 2014, 3:05 p.m., Vinod Kone wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/21464/ > ----------------------------------------------------------- > > (Updated May 14, 2014, 3:05 p.m.) > > > Review request for mesos, Ben Mahler and Jiang Yan Xu. > > > Bugs: MESOS-1276 > https://issues.apache.org/jira/browse/MESOS-1276 > > > Repository: mesos-git > > > Description > ------- > > See summary. > > > Diffs > ----- > > src/slave/constants.hpp c0975254d51fc21dbf3bc006b3169886347f0a3f > src/slave/constants.cpp 1854b16f2c1ed2ae51d2061b0338c3eda4f3b403 > src/slave/flags.hpp 8616817b9602f6ccf56e2af61f36c1bd295df1a1 > src/slave/slave.hpp 29d2a1607a2b3c4443ea14d1cc2b61a065df3cad > src/slave/slave.cpp f8ed65bf7b7e4f3c0834c9e22a525137856e9b23 > src/tests/fault_tolerance_tests.cpp > 4796149beb10a6c668762f5efecd86520b809c42 > src/tests/master_tests.cpp 7aa678afc94869c8243485bd0604532dec43a1e2 > src/tests/mesos.cpp 242d98ad195a8ab1256918c48a2956e2e085d26d > src/tests/slave_recovery_tests.cpp 85c57b29f6a56683e0df9788dea64ebb36e00812 > src/tests/slave_tests.cpp dfbc6481a3a1c6fc234dea48bcfe14deab0bea86 > > Diff: https://reviews.apache.org/r/21464/diff/ > > > Testing > ------- > > make check > > > Thanks, > > Vinod Kone > >
