----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/66311/#review201754 -----------------------------------------------------------
src/resource_provider/manager.cpp Lines 244-249 (patched) <https://reviews.apache.org/r/66311/#comment283341> Nit: Please fix the indentation. src/resource_provider/manager.cpp Line 222 (original), 253-259 (patched) <https://reviews.apache.org/r/66311/#comment283345> If this is not called elsewhere, how about not exposing this as a function but put in it `initialize()`? src/resource_provider/manager.cpp Lines 266-270 (patched) <https://reviews.apache.org/r/66311/#comment283343> ``` // ... actor's indox, which could become large if a big ... ^^^^^^^ ^^^^^^^ ^^ ``` I'm not a native speaker though, so please drop this if I'm incorrect ;) src/resource_provider/registrar.cpp Lines 199-205 (original), 204-208 (patched) <https://reviews.apache.org/r/66311/#comment283346> I just realized that I missed one thing here: if `recover()` is called before `recovered` is assigned, it will return a future that is forever pending. We can do one of the followings to resolve this: 1. Revert `recovered` back to an `Option<Future<Nothing>>`, move this assignment back to `recover()` and guard it with `if (recovered.isNone())`, then call `recover()` here. 2. Make `recovered` a `Promise<Nothing>` as we do in `ResourceProviderManagerProcess` above, the do ``` recovered.associate(state.fetch<Registry>(NAME).then(...)); ``` 3. Don't do anything. Since this is an internal class and the exposed `GenericRegistrar` always dispatch `recover()` to this actor, `initialize()` is guaranteed to always called before `recover()`. This relies on a convention between this actor implementation and the `GenericRegistrar` class. I think either of the 3 is okay. Personally I would prefer adjusting either this class or the `ResourceProviderManagerProcess` class to make the two consistent though. src/resource_provider/registrar.cpp Line 215 (original), 226 (patched) <https://reviews.apache.org/r/66311/#comment283347> `undiscardable(recovered).then(...)` or `recover().then(...)`. src/resource_provider/registrar.cpp Line 284 (original), 292 (patched) <https://reviews.apache.org/r/66311/#comment283348> This parameter is no longer needed. - Chun-Hung Hsiao On April 23, 2018, 11:19 a.m., Benjamin Bannier wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/66311/ > ----------------------------------------------------------- > > (Updated April 23, 2018, 11:19 a.m.) > > > Review request for mesos, Chun-Hung Hsiao, Jie Yu, and Jan Schlicht. > > > Bugs: MESOS-8735 > https://issues.apache.org/jira/browse/MESOS-8735 > > > Repository: mesos > > > Description > ------- > > This patch adjusts the control flow of the resource provider manager > so that we can in the future make use of persisted resource provider > information. While this patch sets up the needed flow, it does not > implement recovery logic, yet. > > > Diffs > ----- > > src/resource_provider/manager.cpp 68e1866986bfb91bf8355099ee1f0a2a86aba39a > src/resource_provider/registrar.hpp > 39f45b0a2a7c35bfe72a9305f5248409e4a3ef45 > src/resource_provider/registrar.cpp > 92ef9aecb1e93d10f46e53984391558f9901a60b > src/tests/resource_provider_manager_tests.cpp > c52541bf130ccf4795b989b53331176a64a097ea > > > Diff: https://reviews.apache.org/r/66311/diff/7/ > > > Testing > ------- > > `make check` > > > Thanks, > > Benjamin Bannier > >
