Re: Review Request 43321: Speeded up SchedulerTest.Decline by advancing the clock.

2016-04-12 Thread Alexander Rukletsov 

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


Fix it, then Ship it!




I'll fix the last nit and commit shortly.


src/tests/scheduler_tests.cpp (line 1075)


Any reason why not resuming right after advancing?


- Alexander Rukletsov


On April 9, 2016, 9:17 a.m., Shuai Lin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/43321/
> ---
> 
> (Updated April 9, 2016, 9:17 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 7956da3480c06637b6893e05f2ed92c4bb8d089f 
> 
> 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)
> ```
> 
> Repeatedly tested with:
> 
> ```sh
> ./bin/mesos-tests.sh --gtest_filter=ContentType/SchedulerTest.Decline/* 
> --gtest_repeat=1000 --gtest_break_on_failure
> ```
> 
> 
> Thanks,
> 
> Shuai Lin
> 
>

Re: Review Request 43321: Speeded up SchedulerTest.Decline by advancing the clock.

2016-04-09 Thread Mesos ReviewBot 

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



Patch looks great!

Reviews applied: [43321]

Passed command: export OS='ubuntu:14.04' CONFIGURATION='--verbose' 
COMPILER='gcc' ENVIRONMENT='GLOG_v=1 MESOS_VERBOSE=1'; ./support/docker_build.sh

- Mesos ReviewBot


On April 9, 2016, 9:17 a.m., Shuai Lin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/43321/
> ---
> 
> (Updated April 9, 2016, 9:17 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 7956da3480c06637b6893e05f2ed92c4bb8d089f 
> 
> 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)
> ```
> 
> Repeatedly tested with:
> 
> ```sh
> ./bin/mesos-tests.sh --gtest_filter=ContentType/SchedulerTest.Decline/* 
> --gtest_repeat=1000 --gtest_break_on_failure
> ```
> 
> 
> Thanks,
> 
> Shuai Lin
> 
>

Re: Review Request 43321: Speeded up SchedulerTest.Decline by advancing the clock.

2016-04-09 Thread Shuai Lin 

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

(Updated April 9, 2016, 9:17 a.m.)


Review request for mesos and Alexander Rukletsov.


Changes
---

Rebased to latest master.


Bugs: MESOS-4175
https://issues.apache.org/jira/browse/MESOS-4175


Repository: mesos


Description
---

Speeded up SchedulerTest.Decline by advancing the clock.


Diffs (updated)
-

  src/tests/scheduler_tests.cpp 7956da3480c06637b6893e05f2ed92c4bb8d089f 

Diff: https://reviews.apache.org/r/43321/diff/


Testing (updated)
---

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)
```

Repeatedly tested with:

```sh
./bin/mesos-tests.sh --gtest_filter=ContentType/SchedulerTest.Decline/* 
--gtest_repeat=1000 --gtest_break_on_failure
```


Thanks,

Shuai Lin

Re: Review Request 43321: Speeded up SchedulerTest.Decline by advancing the clock.

2016-04-08 Thread Alexander Rukletsov 

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



Could you please rebase it?

- Alexander Rukletsov


On March 30, 2016, 1:22 p.m., Shuai Lin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/43321/
> ---
> 
> (Updated March 30, 2016, 1:22 p.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 70c5b218aa231b21277580567d92f31c16a95efb 
> 
> 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
> 
>

Re: Review Request 43321: Speeded up SchedulerTest.Decline by advancing the clock.

2016-02-28 Thread Mesos ReviewBot 

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



Patch looks great!

Reviews applied: [43321]

Passed command: export OS='ubuntu:14.04' CONFIGURATION='--verbose' 
COMPILER='gcc' ENVIRONMENT='GLOG_v=1 MESOS_VERBOSE=1'; ./support/docker_build.sh

- Mesos ReviewBot


On Feb. 29, 2016, 3:11 a.m., Shuai Lin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/43321/
> ---
> 
> (Updated Feb. 29, 2016, 3:11 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 70c5b218aa231b21277580567d92f31c16a95efb 
> 
> 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
> 
>

Re: Review Request 43321: Speeded up SchedulerTest.Decline by advancing the clock.

2016-02-28 Thread Shuai Lin 

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

(Updated Feb. 29, 2016, 3:11 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 (updated)
-

  src/tests/scheduler_tests.cpp 70c5b218aa231b21277580567d92f31c16a95efb 

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

Re: Review Request 43321: Speeded up SchedulerTest.Decline by advancing the clock.

2016-02-12 Thread Shuai Lin 


> On Feb. 9, 2016, 2:29 p.m., Guangya Liu wrote:
> > src/tests/scheduler_tests.cpp, line 839
> > 
> >
> > 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?
> 
> Shuai Lin wrote:
> 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.
> 
> Guangya Liu wrote:
> In a multi-core environment, is it possible for the 
> `HierarchicalAllocatorProcess::recoverResource` and 
> `HierarchicalAllocatorProcess::batch()` be proceed almost same time?

After a discussion on IRC with @gyliu, we agreed that the race condition is not 
possible (thus `Clock::settle()` is not neededed here) because libprocess 
guarantees only one event is handled at a time for any actor.

https://github.com/apache/mesos/blob/0.27.0/3rdparty/libprocess/README.md#processes-and-the-asynchronous-pimpl-pattern


- Shuai


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


On Feb. 12, 2016, 12:15 p.m., Shuai Lin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/43321/
> ---
> 
> (Updated Feb. 12, 2016, 12:15 p.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 37f1709 
> 
> 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
> 
>

Re: Review Request 43321: Speeded up SchedulerTest.Decline by advancing the clock.

2016-02-12 Thread Shuai Lin 

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

(Updated Feb. 12, 2016, 12:15 p.m.)


Review request for mesos and Alexander Rukletsov.


Changes
---

Fixed code comments.


Bugs: MESOS-4175
https://issues.apache.org/jira/browse/MESOS-4175


Repository: mesos


Description
---

Speeded up SchedulerTest.Decline by advancing the clock.


Diffs (updated)
-

  src/tests/scheduler_tests.cpp 37f1709 

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

Re: Review Request 43321: Speeded up SchedulerTest.Decline by advancing the clock.

2016-02-12 Thread Guangya Liu 

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


Fix it, then Ship it!




Ship It!


src/tests/scheduler_tests.cpp (line 896)


s/dispatch/dispatched

s/recoverResources/`recoverResources`


- Guangya Liu


On 二月 12, 2016, 12:15 p.m., Shuai Lin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/43321/
> ---
> 
> (Updated 二月 12, 2016, 12:15 p.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 37f1709 
> 
> 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
> 
>

Re: Review Request 43321: Speeded up SchedulerTest.Decline by advancing the clock.

2016-02-12 Thread Shuai Lin 


> On Feb. 12, 2016, 1:36 p.m., Guangya Liu wrote:
> > src/tests/scheduler_tests.cpp, line 896
> > 
> >
> > s/dispatch/dispatched
> > 
> > s/recoverResources/`recoverResources`

- `the dispatch event` is used like `struct DispatchEvent` 
[here](https://github.com/apache/mesos/blob/0.27.0/3rdparty/libprocess/include/process/event.hpp#L31)
- recoverResources - sorry but I don't see the difference


- Shuai


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


On Feb. 12, 2016, 12:15 p.m., Shuai Lin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/43321/
> ---
> 
> (Updated Feb. 12, 2016, 12:15 p.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 37f1709 
> 
> 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
> 
>

Re: Review Request 43321: Speeded up SchedulerTest.Decline by advancing the clock.

2016-02-12 Thread Shuai Lin 

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

(Updated Feb. 12, 2016, 1:48 p.m.)


Review request for mesos and Alexander Rukletsov.


Changes
---

Updated comments.


Bugs: MESOS-4175
https://issues.apache.org/jira/browse/MESOS-4175


Repository: mesos


Description
---

Speeded up SchedulerTest.Decline by advancing the clock.


Diffs (updated)
-

  src/tests/scheduler_tests.cpp 37f1709 

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

Re: Review Request 43321: Speeded up SchedulerTest.Decline by advancing the clock.

2016-02-12 Thread Mesos ReviewBot 

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



Patch looks great!

Reviews applied: [43321]

Passed command: export OS='ubuntu:14.04' CONFIGURATION='--verbose' 
COMPILER='gcc' ENVIRONMENT='GLOG_v=1 MESOS_VERBOSE=1'; ./support/docker_build.sh

- Mesos ReviewBot


On Feb. 12, 2016, 1:48 p.m., Shuai Lin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/43321/
> ---
> 
> (Updated Feb. 12, 2016, 1:48 p.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 37f1709 
> 
> 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
> 
>

Re: Review Request 43321: Speeded up SchedulerTest.Decline by advancing the clock.

2016-02-11 Thread Guangya Liu 

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




src/tests/scheduler_tests.cpp (line 836)


I think here is not `finish processing the decline call` but `Make sure the 
recoverResources event has been queued.` At this time, the `decline` call is 
not finished yet as the `recoverResources` was just queued.


- Guangya Liu


On 二月 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 二月 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
> 
>

Re: Review Request 43321: Speeded up SchedulerTest.Decline by advancing the clock.

2016-02-11 Thread Guangya Liu 


> On 二月 9, 2016, 2:29 p.m., Guangya Liu wrote:
> > src/tests/scheduler_tests.cpp, line 839
> > 
> >
> > 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?
> 
> Shuai Lin wrote:
> 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.

In a multi-core environment, is it possible for the 
`HierarchicalAllocatorProcess::recoverResource` and 
`HierarchicalAllocatorProcess::batch()` be proceed almost same time?


- Guangya


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


On 二月 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 二月 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
> 
>

Re: Review Request 43321: Speeded up SchedulerTest.Decline by advancing the clock.

2016-02-10 Thread Shuai Lin 


> On Feb. 9, 2016, 2:29 p.m., Guangya Liu wrote:
> > src/tests/scheduler_tests.cpp, line 839
> > 
> >
> > 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
> 
>

Re: Review Request 43321: Speeded up SchedulerTest.Decline by advancing the clock.

2016-02-10 Thread Guangya Liu 


> On 二月 9, 2016, 2:29 p.m., Guangya Liu wrote:
> > src/tests/scheduler_tests.cpp, line 839
> > 
> >
> > 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?

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?


- Guangya


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


On 二月 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 二月 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
> 
>

Re: Review Request 43321: Speeded up SchedulerTest.Decline by advancing the clock.

2016-02-09 Thread Guangya Liu 

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




src/tests/scheduler_tests.cpp (line 839)


Do we need Clock::settle() here to make sure the `recoverResources` 
messages to be dispatched and processed completely?



src/tests/scheduler_tests.cpp (line 850)


Does this still needed?


- Guangya Liu


On 二月 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 二月 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
> 
>

Re: Review Request 43321: Speeded up SchedulerTest.Decline by advancing the clock.

2016-02-09 Thread haosdent huang 


> On Feb. 9, 2016, 2:29 p.m., Guangya Liu wrote:
> > src/tests/scheduler_tests.cpp, line 839
> > 
> >
> > Do we need Clock::settle() here to make sure the `recoverResources` 
> > messages to be dispatched and processed completely?

+1 for add settle


> On Feb. 9, 2016, 2:29 p.m., Guangya Liu wrote:
> > src/tests/scheduler_tests.cpp, line 850
> > 
> >
> > Does this still needed?

I think still need, we don't sure what would happend in `Shutdown()` in the 
future.


- haosdent


---
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
> 
>

Re: Review Request 43321: Speeded up SchedulerTest.Decline by advancing the clock.

2016-02-09 Thread haosdent huang 


> On Feb. 9, 2016, 2:29 p.m., Guangya Liu wrote:
> > src/tests/scheduler_tests.cpp, line 850
> > 
> >
> > Does this still needed?
> 
> haosdent huang wrote:
> I think still need, we don't sure what would happend in `Shutdown()` in 
> the future.
> 
> Guangya Liu wrote:
> I raise this issue because I saw that some cases do not include 
> `Clock::resume();` while some cases do include, it is better add some 
> comments here to clarify why does `Clock::resume();` is needed here.

Usually we call `Clock::resume()` if we don't want to pause the Clock after we 
`Clock::pause` and `Clock::advance`.


- haosdent


---
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
> 
>

Re: Review Request 43321: Speeded up SchedulerTest.Decline by advancing the clock.

2016-02-09 Thread Shuai Lin 


> On Feb. 9, 2016, 2:29 p.m., Guangya Liu wrote:
> > src/tests/scheduler_tests.cpp, line 850
> > 
> >
> > Does this still needed?
> 
> haosdent huang wrote:
> I think still need, we don't sure what would happend in `Shutdown()` in 
> the future.
> 
> Guangya Liu wrote:
> I raise this issue because I saw that some cases do not include 
> `Clock::resume();` while some cases do include, it is better add some 
> comments here to clarify why does `Clock::resume();` is needed here.
> 
> haosdent huang wrote:
> Usually we call `Clock::resume()` if we don't want to pause the Clock 
> after we `Clock::pause` and `Clock::advance`.

I also noticed some of the tests call `Clock::resume()` while others don't. The 
only thing I have encoutered is if there is a task left running at the end of 
the test, wihtout a call to `Clock::resume()` the test would timeout and fail. 

In short, I guess it's no harm to keep it here before there is a general 
guideline for the pattern.


- 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
> 
>

Re: Review Request 43321: Speeded up SchedulerTest.Decline by advancing the clock.

2016-02-09 Thread Guangya Liu 


> On 二月 9, 2016, 2:29 p.m., Guangya Liu wrote:
> > src/tests/scheduler_tests.cpp, line 839
> > 
> >
> > 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?

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()`


- Guangya


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


On 二月 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 二月 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
> 
>

Re: Review Request 43321: Speeded up SchedulerTest.Decline by advancing the clock.

2016-02-09 Thread Guangya Liu 


> On 二月 9, 2016, 2:29 p.m., Guangya Liu wrote:
> > src/tests/scheduler_tests.cpp, line 850
> > 
> >
> > Does this still needed?
> 
> haosdent huang wrote:
> I think still need, we don't sure what would happend in `Shutdown()` in 
> the future.

I raise this issue because I saw that some cases do not include 
`Clock::resume();` while some cases do include, it is better add some comments 
here to clarify why does `Clock::resume();` is needed here.


- Guangya


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


On 二月 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 二月 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
> 
>

Re: Review Request 43321: Speeded up SchedulerTest.Decline by advancing the clock.

2016-02-09 Thread Shuai Lin 


> On Feb. 9, 2016, 2:29 p.m., Guangya Liu wrote:
> > src/tests/scheduler_tests.cpp, line 839
> > 
> >
> > 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

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?


- 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
> 
>

Re: Review Request 43321: Speeded up SchedulerTest.Decline by advancing the clock.

2016-02-09 Thread Shuai Lin 


> On Feb. 9, 2016, 2:29 p.m., Guangya Liu wrote:
> > src/tests/scheduler_tests.cpp, line 839
> > 
> >
> > 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()`

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?


- 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
> 
>

Review Request 43321: Speeded up SchedulerTest.Decline by advancing the clock.

2016-02-07 Thread Shuai Lin 

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

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

Re: Review Request 43321: Speeded up SchedulerTest.Decline by advancing the clock.

2016-02-07 Thread haosdent huang 

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


Ship it!




Ship It!

- haosdent huang


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
> 
>

Re: Review Request 43321: Speeded up SchedulerTest.Decline by advancing the clock.

2016-02-07 Thread Mesos ReviewBot 

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



Patch looks great!

Reviews applied: [43321]

Passed command: export OS='ubuntu:14.04' CONFIGURATION='--verbose' 
COMPILER='gcc' ENVIRONMENT='GLOG_v=1 MESOS_VERBOSE=1'; ./support/docker_build.sh

- Mesos ReviewBot


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
> 
>