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



src/tests/scheduler_tests.cpp (lines 999 - 1008)
<https://reviews.apache.org/r/39548/#comment161781>

    Wondering, why did you change order here i.e. move this piece of code up ? 
    
    Now, with using `FUTURE_DISPATCH` you can gurrantee that `Suppress` would 
be completed before the `Clock` is advanced. Am I missing something ?



src/tests/scheduler_tests.cpp (line 1007)
<https://reviews.apache.org/r/39548/#comment161783>

    This alone won't suffice. AFAIK, the `Future` returned by `FUTURE_DISPATCH` 
is marked ready when the function is invoked not neccessarily when the function 
has completely executed.
    
    You would want to pause/settle the clock too. The modified code would look 
like:
    
    ```
     Future<Nothing> suppressOffers =
        FUTURE_DISPATCH(_, &MesosAllocatorProcess::suppressOffers);
    
      {
        Call call;
        call.mutable_framework_id()->CopyFrom(id);
        call.set_type(Call::SUPPRESS);
    
        mesos.send(call);
      }
    
      AWAIT_READY(suppressOffers);
      
      // Wait for suppress to be complete.
      Clock::pause();
      Clock::settle();
      
      // No offers should be sent within 100 mins because the framework
      // suppressed offers.
      Clock::advance(Minutes(100));
      Clock::settle();
    ```
    
    Here is some more info: 
http://mesos.apache.org/documentation/latest/testing-patterns/ . What do you 
think ?


- Anand Mazumdar


On Oct. 23, 2015, 2:32 a.m., Guangya Liu wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/39548/
> -----------------------------------------------------------
> 
> (Updated Oct. 23, 2015, 2:32 a.m.)
> 
> 
> Review request for mesos and Vinod Kone.
> 
> 
> Bugs: MESOS-3733
>     https://issues.apache.org/jira/browse/MESOS-3733
> 
> 
> Repository: mesos
> 
> 
> Description
> -------
> 
> Root Cause: The reason is that the DECLINE call set filter as 1hr,
> the Clock::advance set as 100m. A race condition is that both DECLINE
> and SUPPRESS started up in different threads and the call Clock::advance
> may be called before SUPPRESS finished. The clock advanced for 100m which
> is greater than 1hr, this caused the allocator start to allocate resource
> again and ASSERT_TRUE(event.isPending()) will be failed.
> 
> Solution: Call SUPPRESS first, and make sure SUPPRESS call ready before
> call DECLINE.
> 
> 
> Diffs
> -----
> 
>   src/tests/scheduler_tests.cpp 7946cb48d62f4ed6d0fdbc771746518e31921f97 
> 
> Diff: https://reviews.apache.org/r/39548/diff/
> 
> 
> Testing
> -------
> 
> Platform: Ubuntu 14.04
> make 
> make check
> bin/mesos-tests.sh --gtest_filter="ContentType/SchedulerTest.Suppress/*"  
> --gtest_repeat=-1 --gtest_break_on_failure
> 
> 
> Thanks,
> 
> Guangya Liu
> 
>

Reply via email to