> On Feb. 9, 2016, 2:29 p.m., Guangya Liu wrote: > > src/tests/scheduler_tests.cpp, line 839 > > <https://reviews.apache.org/r/43321/diff/1/?file=1237111#file1237111line839> > > > > Do we need Clock::settle() here to make sure the `recoverResources` > > messages to be dispatched and processed completely? > > haosdent huang wrote: > +1 for add settle > > Shuai Lin wrote: > Hello haosdent and Guangya, > > I don't think `Clock::settle()` is needed here. > > I guess your rationale is we need to be sure the decline call is > processed *before* the next around of allocation is executed, which I totally > agree. But we already have it without `clock::settle()`, here is my > understanding: > > - We advance the clock after the dispatch event of `recoverResources` is > enqueued. And by advancing the clock, we can be sure the > `HierarchicalAllocatorProcess::batch()` function, which does the allocation > work, being added to the event loop. > > - Since the `recoverResources` is dispatched before > `HierarchicalAllocatorProcess::batch()`, it would always be processed first > by allocator. > > What do you think? > > Guangya Liu wrote: > I think we cannot make sure that the > `HierarchicalAllocatorProcess::batch()` is always handled before > `recoverResources` for some race condition cases, you may see that most of > the `advance()` always including `Clock::settle()` > > Shuai Lin wrote: > Hello Guangya, Could you please elaborate more on the "race condition > cases"? IMHO libprocess guarantees for a given actor, first enqueued event is > also hanlded first, no? > > Guangya Liu wrote: > My understanding is that the `decline` will involve two libprocess calls > `decline` and `recoverResources`, there might be problem if > `HierarchicalAllocatorProcess::batch()` is called after `decline` but before > `recoverResources`, comments?
Let's inspect the behavior of the allocator actor: - When `AWAIT_READY(recoverResources)` returns, we can be sure that a dispatch event of `HierarchicalAllocatorProcess::recoverResource` for the allocator actor is already in the run queue. - After that we advance the clock so that a dispatch event of `HierarchicalAllocatorProcess::batch()` is enqueued immediately (instead of waiting for a duration of `flags.allocation_interval`). - Since the `HierarchicalAllocatorProcess::recoverResource` is enquened first, we can be sure it's called before `HierarchicalAllocatorProcess::batch()` is called. - Shuai ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/43321/#review118391 ----------------------------------------------------------- On Feb. 8, 2016, 4:20 a.m., Shuai Lin wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/43321/ > ----------------------------------------------------------- > > (Updated Feb. 8, 2016, 4:20 a.m.) > > > Review request for mesos and Alexander Rukletsov. > > > Bugs: MESOS-4175 > https://issues.apache.org/jira/browse/MESOS-4175 > > > Repository: mesos > > > Description > ------- > > Speeded up SchedulerTest.Decline by advancing the clock. > > > Diffs > ----- > > src/tests/scheduler_tests.cpp 4e2db2ac40c59b9b9a97cd214b3cd1e727a4f0ad > > Diff: https://reviews.apache.org/r/43321/diff/ > > > Testing > ------- > > sudo make check -j2 GTEST_FILTER='ContentType/SchedulerTest.Decline/* > > ```sh > [ RUN ] ContentType/SchedulerTest.Decline/0 > [ OK ] ContentType/SchedulerTest.Decline/0 (114 ms) > [ RUN ] ContentType/SchedulerTest.Decline/1 > [ OK ] ContentType/SchedulerTest.Decline/1 (98 ms) > ``` > > > Thanks, > > Shuai Lin > >
