> On Jan. 8, 2016, 7:16 a.m., Anand Mazumdar wrote:
> > LGTM. Two minor issues:
> > 
> > 1. May be we can escape without passing the `Master` pointer around?
> > 2. Would be great to have a test to go with this?

I am submitting the test as a separate patch.


> On Jan. 8, 2016, 7:16 a.m., Anand Mazumdar wrote:
> > src/master/master.hpp, line 1356
> > <https://reviews.apache.org/r/42053/diff/1/?file=1186664#file1186664line1356>
> >
> >     hmmm.. Do we need to pass an pointer to `Master` here? Looks like a 
> > overkill to me.
> >     
> >     Can't we either pass the `Flags` object or just pass on the value of 
> > `flags.max_completed_frameworks` here?

I've changed it to take a flags parameter instead of a pointer to master.


- Kevin


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


On Jan. 11, 2016, 9:39 p.m., Kevin Klues wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/42053/
> -----------------------------------------------------------
> 
> (Updated Jan. 11, 2016, 9:39 p.m.)
> 
> 
> Review request for mesos and Ben Mahler.
> 
> 
> Bugs: MESOS-3307
>     https://issues.apache.org/jira/browse/MESOS-3307
> 
> 
> Repository: mesos
> 
> 
> Description
> -------
> 
> The default size of the buffers used to hold the state of completed
> tasks/frameworks is very large. However, many frameworks don't care much
> about this information when requesting a master's state. Moreover, if a
> large number of frameworks request this state simultaneously, the
> master can quickly become overwhelmed because the process of generating
> this state both blocks the master and takes up a lot of cycles. By
> allowing the master to configure the size of the buffers used to hold
> this state, we give it the power to significantly reduce the amount of
> state it needs to maintain.
> 
> This change allows the master to limit the size of this state via
> command line flags.
> 
> This commit is based on a pull request generated by Felix Bechstein at:
> https://github.com/apache/mesos/pull/82
> 
> Review: https://reviews.apache.org/r/42053
> 
> 
> Diffs
> -----
> 
>   src/master/constants.hpp ebab341e58035d4b579828add752c1ee37efeb95 
>   src/master/constants.cpp 77dd31430776e4f24e6e074c1470edcb19e58449 
>   src/master/flags.hpp d923b1b0444d7e9023f1db4cbc4f7d4b84c20ff5 
>   src/master/flags.cpp 88909590ff421421659e6faac7f3444bdc57b630 
>   src/master/master.hpp f02d165874fa8023675e545793de699aeecae29b 
>   src/master/master.cpp 2d9b7f9540574aa3ef9e5af3b2b8922dffeebac8 
> 
> Diff: https://reviews.apache.org/r/42053/diff/
> 
> 
> Testing
> -------
> 
> On Darwin I launched a master with:
> 
> ./bin/mesos-master.sh --ip=127.0.0.1 --work_dir=/var/lib/mesos 
> --max_completed_tasks_per_framework=2 --max_completed_frameworks=1
> 
> and a slave with:
> 
> ./bin/mesos-slave.sh --master=127.0.0.1:5050
> 
> and then ran a bunch of instances of:
> 
> ./src/test-framework --master=127.0.0.1:5050
> 
> each of which runs 5 tasks to completion
> 
> I then ran:
> 
> curl http://localhost:5050/tasks
> 
> and verified that only 1 framework and 2 of its completed tasks were given 
> back to me in the json that was returned.  I repeated this for a number of 
> other configurations with max_completed_frameworks=0..2 and 
> max_completed_tasks_per_framework=0..5 and verified visually that the proper 
> number of tasks/frameworks were being returned by the /tasks endpoint.
> 
> 
> Thanks,
> 
> Kevin Klues
> 
>

Reply via email to