----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/30511/#review70695 -----------------------------------------------------------
Ship it! I recall Yan and I discussed improving the BoundedRateLimiter abstraction to provide a interface that returns failed futures when the bound is reached, but I don't think we documented it or the implications of such a change. Mind adding a small TODO for this? src/master/master.hpp <https://reviews.apache.org/r/30511/#comment116043> Any reason to nest this in the Framework struct? Seems like a more general abstraction. We could hide it in the master.cpp since you should be able to forward declare here? Then we can have a TODO on BoundedRateLimiter to provide a cleaner abstraction (i.e. provide an `aquire` that fails a future when capacity is exceeded, if possible. I believe there are some subtleties there IIRC). src/master/master.cpp <https://reviews.apache.org/r/30511/#comment116042> Hm.. mind indenting this to show that it's a continuation of the < operation for the last line? - Ben Mahler On Feb. 2, 2015, 6:39 p.m., Vinod Kone wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/30511/ > ----------------------------------------------------------- > > (Updated Feb. 2, 2015, 6:39 p.m.) > > > Review request for mesos, Ben Mahler and Jiang Yan Xu. > > > Bugs: MESOS-1148 > https://issues.apache.org/jira/browse/MESOS-1148 > > > Repository: mesos > > > Description > ------- > > In the subsequent review a slave related rate limiter is added. So moved the > framework related rate limiters inside 'frameworks'. > > No functional changes. > > > Diffs > ----- > > src/master/master.hpp 337e00aa46ea127f3667e3383d631c3fb8e22f30 > src/master/master.cpp 10056861b95ed9453c971787982db7d09f09f323 > > Diff: https://reviews.apache.org/r/30511/diff/ > > > Testing > ------- > > make check > > > Thanks, > > Vinod Kone > >
