> On April 18, 2014, 12:46 a.m., Ben Mahler wrote:
> > src/log/recover.cpp, lines 239-240
> > <https://reviews.apache.org/r/18600/diff/10/?file=561411#file561411line239>
> >
> >     Maybe a good TODO would be on the Log interface? I'm curious why we 
> > would allow the 'quorum' to be specified explicitly when constructing a Log 
> > with a set of pids. Are there reasons for having larger than necessary 
> > quorum sizes?
> >     
> >     We don't seem to be validating the quorum size is large enough w.r.t 
> > 'pids'?

> I'm curious why we would allow the 'quorum' to be specified explicitly
> when constructing a Log with a set of pids. Are there reasons for
> having larger than necessary quorum sizes?

Technically, quorum size does not necessarily has to be "floor(cluster size/2) 
+ 1".

For example, one may wanna choose to use quorum == cluster size in some cases 
(for high redundancy).


> On April 18, 2014, 12:46 a.m., Ben Mahler wrote:
> > src/log/recover.cpp, line 325
> > <https://reviews.apache.org/r/18600/diff/10/?file=561411#file561411line325>
> >
> >     Do we want to chain this new run behind 'future' transitioning from 
> > pending or is it safe to proceed immediately with the new protocol run?

Re-wrote it after the 'select' bug has been fixed in
https://reviews.apache.org/r/20533/


> On April 18, 2014, 12:46 a.m., Ben Mahler wrote:
> > src/tests/log_tests.cpp, lines 1749-1751
> > <https://reviews.apache.org/r/18600/diff/10/?file=561412#file561412line1749>
> >
> >     We have macros to do this in one line if you like:
> >     
> >     AWAIT_EQ
> >     AWAIT_ASSERT_EQ
> >     AWAIT_EXPECT_EQ
> >     
> >     Ditto elsewhere.

You'll gonna need AWAIT_EXPECT_SOME_EQ(...).

Will just leave it for now.


> On April 18, 2014, 12:46 a.m., Ben Mahler wrote:
> > src/log/recover.cpp, line 349
> > <https://reviews.apache.org/r/18600/diff/9-10/?file=549174#file549174line349>
> >
> >     10 Seconds seems like quite a lot when we expect operators to start 
> > replicas sequentially? What would be the consequences of a lower timeout?

We'll just retry more frequently. I'll keep 10 seconds for now (to be 
consistent with the catchup retry timeout) unless it becomes a problem.


- Jie


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


On April 16, 2014, 11:43 p.m., Jie Yu wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/18600/
> -----------------------------------------------------------
> 
> (Updated April 16, 2014, 11:43 p.m.)
> 
> 
> Review request for mesos, Benjamin Hindman and Ben Mahler.
> 
> 
> Bugs: MESOS-984
>     https://issues.apache.org/jira/browse/MESOS-984
> 
> 
> Repository: mesos-git
> 
> 
> Description
> -------
> 
> See summary.
> 
> 
> Diffs
> -----
> 
>   src/log/log.hpp 6787c80 
>   src/log/log.cpp 9dd992f 
>   src/log/recover.hpp 634bc06 
>   src/log/recover.cpp 688da5f 
>   src/tests/log_tests.cpp 4f08927 
> 
> Diff: https://reviews.apache.org/r/18600/diff/
> 
> 
> Testing
> -------
> 
> make check
> 
> 
> Thanks,
> 
> Jie Yu
> 
>

Reply via email to