> On Nov. 6, 2013, 6:48 a.m., Benjamin Hindman wrote:
> > src/log/replica.hpp, line 58
> > <https://reviews.apache.org/r/14946/diff/6/?file=377559#file377559line58>
> >
> >     Hmm, what do you mean by backwards compatibility here? Most old users 
> > will want to turn strict on, and most new users will want to have it on by 
> > default and they'll likely miss it since it's a defaulted parameter. What's 
> > the issue in making strict = true by default?

Hah, I have another separate patch which will enable the 'strict' mode by 
default. I will merge that with this patch.


> On Nov. 6, 2013, 6:48 a.m., Benjamin Hindman wrote:
> > src/log/replica.cpp, lines 1209-1222
> > <https://reviews.apache.org/r/14946/diff/6/?file=377560#file377560line1209>
> >
> >     Why can't the default metadata status just be EMPTY? Then no need to 
> > set it explicitly right?

This is for backward compatibility concern. Suppose a replica has the old 
format (no meta data, only the promise is stored), I think we should to set its 
state to VOTING by default. Thoughts?


> On Nov. 6, 2013, 6:48 a.m., Benjamin Hindman wrote:
> > src/messages/log.proto, line 186
> > <https://reviews.apache.org/r/14946/diff/6/?file=377561#file377561line186>
> >
> >     I think reusing the RecoverRequest for both the network broadcast and a 
> > RecoverProcess adds unnecessarily complexity. Why can't the RecoverProcess 
> > just use it's Shared<Replica> to explicitly ask the Replica to set update 
> > it's metadata?

That was my initial solution. The problem is that you need to mark setState (or 
update) as a const function, which is OK because Replica is a wrapper anyway, 
but is not intuitive. What do you think?

Or we may want to introduce a WritableShared<T>(const Shared<T>& shared) to 
allow writing?


- Jie


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


On Nov. 5, 2013, 12:52 a.m., Jie Yu wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/14946/
> -----------------------------------------------------------
> 
> (Updated Nov. 5, 2013, 12:52 a.m.)
> 
> 
> Review request for mesos and Benjamin Hindman.
> 
> 
> Bugs: MESOS-736
>     https://issues.apache.org/jira/browse/MESOS-736
> 
> 
> Repository: mesos-git
> 
> 
> Description
> -------
> 
> This is the last patch of a series of patches that implement catch-up 
> replicated log.
> 
> Here is summary of this patch:
> 1) Introduced RecoverRequest/RecoverResponse in log.proto.
> 2) Replaced Promise with ReplicaInfo in log.proto as we need persist recovery 
> information (maintain backwards compatibility).
> 3) A 2-phase empty log start-up algorithm.
> 4) Added a test to test two competing recover processes.
> 
> This is a joint work with Yan Xu.
> 
> 
> Diffs
> -----
> 
>   src/Makefile.am 9780d07 
>   src/log/log.hpp 77edc7a 
>   src/log/recover.hpp PRE-CREATION 
>   src/log/recover.cpp PRE-CREATION 
>   src/log/replica.hpp d1f5ead 
>   src/log/replica.cpp 59a6ff3 
>   src/messages/log.proto 3d5859f 
>   src/tests/log_tests.cpp ff5f86c 
> 
> Diff: https://reviews.apache.org/r/14946/diff/
> 
> 
> Testing
> -------
> 
> bin/mesos-tests.sh --gtest_filter=CoordinatorTest.*:ReplicaTest.*:LogTest.* 
> --gtest_repeat=100
> 
> 
> Thanks,
> 
> Jie Yu
> 
>

Reply via email to