> On July 29, 2017, 12:20 a.m., Jie Yu wrote:
> > src/slave/slave.cpp
> > Lines 6496 (patched)
> > <https://reviews.apache.org/r/61183/diff/1/?file=1784503#file1784503line6496>
> >
> >     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.

Good point about being able to consume the message at least on the agent side 
-- I have updated the code.

I also now use the same log message when an update is send, regardless on 
whether the message was generated in direct message handling or on 
reregistrated.

I added an assertion for `state == RUNNING` to the sending in reregistered 
agent state; as we do not periodically poll the resource provider manager we 
rely on the fact that every update reaches the master. This is different for 
oversubscription where we poll the resource estimator periodically.


- Benjamin


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/61183/#review181736
-----------------------------------------------------------


On July 31, 2017, 5:08 p.m., Benjamin Bannier wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/61183/
> -----------------------------------------------------------
> 
> (Updated July 31, 2017, 5:08 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/2/
> 
> 
> Testing
> -------
> 
> `make check`
> 
> 
> Thanks,
> 
> Benjamin Bannier
> 
>

Reply via email to