> On Aug. 19, 2014, 6:21 p.m., Ben Mahler wrote:
> > src/tests/master_tests.cpp, lines 2134-2136
> > <https://reviews.apache.org/r/22066/diff/4/?file=662801#file662801line2134>
> >
> > This comment is no longer relevant, and we can remove the Clock::resume
>
> Ben Mahler wrote:
> Unfortunately you have to reply on the main review page for ReviewBoard
> to keep the thread of conversation intact, maybe they've fixed that in this
> new version :)
>
> Can you share how it fails when the Clock::resume it provided? So long as
> we pause/advance the clock *after* the offer timeout has been created, the
> timeout should fire once the clock is advanced and remains paused.
>
> Since we call 'delay' before sending the offers to the framework, and we
> have an AWAIT_READY(resourceOffers) before we pause the clock, resuming the
> clock should be unnecessary since we've paused it *after* the delay timer has
> been created.
>
> I must be missing something :)
If I remove Clock::resume(), the test fails with the following error:
[ RUN ] MasterTest.OfferTimeout
../../src/tests/master_tests.cpp:2147: Failure
Failed to wait 10secs for resourceReoffered
../../src/tests/master_tests.cpp:2120: Failure
Actual function call count doesn't match EXPECT_CALL(sched,
resourceOffers(&driver, _))...
Expected: to be called twice
Actual: called once - unsatisfied and active
Don't we need to resume the clock to allow it to satisfy the next resource
offer?
- Kapil
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/22066/#review51039
-----------------------------------------------------------
On Aug. 19, 2014, 9:54 p.m., Kapil Arya wrote:
>
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/22066/
> -----------------------------------------------------------
>
> (Updated Aug. 19, 2014, 9:54 p.m.)
>
>
> Review request for mesos, Adam B, Ben Mahler, Niklas Nielsen, and Timothy
> Chen.
>
>
> Bugs: mesos-186
> https://issues.apache.org/jira/browse/mesos-186
>
>
> Repository: mesos-git
>
>
> Description
> -------
>
> A timer is associated with each newly created offer.
> The offer is rescinded on timeout.
> The timer is disarmed on a launchTask or decline.
>
> This is continuation of Tim's patch: https://reviews.apache.org/r/22796/.
> Revision two represents the latest patch from Tim. I have tried to address
> the comments/concerns from that request into the third revision.
>
>
> Diffs
> -----
>
> src/master/flags.hpp 5e9ecb5
> src/master/master.hpp c9f989a
> src/master/master.cpp 18464ba
> src/tests/master_tests.cpp 9de2424
>
> Diff: https://reviews.apache.org/r/22066/diff/
>
>
> Testing
> -------
>
> Added one more test after Tim's patch to test offer is not rescinded once it
> has been declined.
>
> make check
>
>
> Thanks,
>
> Kapil Arya
>
>
