----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/61183/#review181736 -----------------------------------------------------------
src/slave/slave.cpp Lines 833 (patched) <https://reviews.apache.org/r/61183/#comment257387> typo. src/slave/slave.cpp Lines 833-835 (patched) <https://reviews.apache.org/r/61183/#comment257388> I would start listening for resource provider messages after slave has recovered. (see the place where we start listening from resource estimators). src/slave/slave.cpp Lines 6496 (patched) <https://reviews.apache.org/r/61183/#comment257389> I think we can still process `UPDATE_TOTAL_RESOURCES` message in DISCONNECTED state by updating slave's internal data structure about total resources. We just need to send that new total to the master once the slave is in RUNNING state. However, we should only send the message to the master if slave is in RUNNING state. This logic is indeed very similar to the oversubscription logic. Take a look at the logics there. - Jie Yu On July 27, 2017, 2:49 p.m., Benjamin Bannier wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/61183/ > ----------------------------------------------------------- > > (Updated July 27, 2017, 2:49 p.m.) > > > Review request for mesos, Jie Yu and Jan Schlicht. > > > Repository: mesos > > > Description > ------- > > The agent's resource provider manager sends a > 'ResourceProviderMessage' when its managed resources change. This > commit adds handling in the agent so that an 'UpdateSlaveMessage' is > sent to the master to update the total resource available on the > agent. We also store this total in the agent memory so that it can be > resent on agent resubscription. > > In order to provide push-like handling of the resource provider > manager's message queue, we chain recursive calls to the handler for > continuous processing. Initially, processing is kicked off from > 'Slave::initialize'. In this simple implementation we e.g., provide no > direct way to stop processing of messages, yet, but it can be achieved > by e.g., replacing the manager with a new instance (this would also > require updating routes). > > Since the agent can only send an 'UpdateSlaveMessage' when it is > registered with a master, a simple back-off of 5 s is implemented which > will defer processing of a ready message should the agent not yet have > registered. > > To facilitate logging we add a stringification function for > 'ResourceProviderMessage's. > > > Diffs > ----- > > src/resource_provider/message.hpp 916926bf278de9ed919384a82a452d3ced06bd04 > src/slave/slave.hpp 1fe93dab1b2bef24721cc1bcffebe1b259e96d79 > src/slave/slave.cpp 7381530515f86faf4c3e8f82bcd9483f6cf0498b > src/tests/slave_tests.cpp a089cc47eae41cd6baeffd3f4a7ee7c7984aacbd > > > Diff: https://reviews.apache.org/r/61183/diff/1/ > > > Testing > ------- > > `make check` > > > Thanks, > > Benjamin Bannier > >
