Sounds good. I'll do it today.
On Wed, Nov 6, 2013 at 11:21 AM, Benjamin Hindman <[email protected]> wrote: > How about we do: > > Shared<T> share(); -- in Owned<T> > > and maybe even rename 'upgrade()' to 'own()' in Shared<T>! > > Ben. > > > On Wed, Nov 6, 2013 at 9:17 AM, Jie Yu <[email protected]> wrote: > >> >> >> > 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? >> > >> > Jie Yu wrote: >> > 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? >> > >> > Benjamin Hindman wrote: >> > I guess I'm still unclear about the recovering semantics in the >> first place. What does it mean to have both a RecoverProcess and a >> CoordinatorProcess sharing a replica simultaneously? Can we not give the >> RecoverProcess an Owned<Replica> and then after it completes make it shared? >> >> Oh! Haven't thought about in this way. Yeah, that should work. >> >> We either need to add >> Shared(const Owned<T>& owned); -- in Shared<T> >> >> or >> Shared<T> downgrade(); -- in Owned<T> >> >> Which one do you prefer? >> >> >> - 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 >> > >> > >> >> >
