> On 2012-05-03 22:39:21, John Sirois wrote: > > We talked a bit offline, but to flesh the motivation out: > > > > If the intended use is for the master - then there will never be contended > > state writes and the uuid piece in all this is overkill. Ie: there is one > > master and it either writes to a local leveldb, a distributed log or > > zookeeper - but in any of these cases no write will ever fail in this uuid > > scheme unless there is a programming error where the master does not read > > before write. Are you intending to actually use this to avoid the reads?, > > ie: write -> fail on uuid mismatch, read -> write?
Consider the case where I'm using the distributed log for the implementation of "state". It's possible that master (a) tries to write to the distributed log and fails because it's coordinator is no longer elected. This could occur when master (a) was partitioned and master (b) got elected and master (a) attempts to write some state before it finds out that it is no longer elected (this exact scenario can occur with the Twitter scheduler too). Part of this is because the "election" mechanism is separated from the "state" mechanism (which in many ways is also quite nice). Now, to give these same semantics using ZooKeeper for state requires something like the UUID mechanism (or possibly very complicated code that watches znodes ...). That is, it's possible that master (a) attempts to swap an Entry in ZooKeeper before it kills itself because master (b) has been elected. In this case, we want to make sure master (a) does not write over what master (b) might have already written. My intent was to provide these "strong" semantics so that this abstraction may be used in general environments. - Benjamin ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/4981/#review7529 ----------------------------------------------------------- On 2012-05-03 19:50:24, Benjamin Hindman wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/4981/ > ----------------------------------------------------------- > > (Updated 2012-05-03 19:50:24) > > > Review request for mesos, John Sirois and Vinod Kone. > > > Summary > ------- > > This is the beginning of a the components for saving "state" information, > including what slaves are connected, what frameworks are running, etc. I'll > be adding a ZooKeeperState implementation soon, and the master and it's > components will use it to save state in a distributed way. > > > Diffs > ----- > > src/messages/state.proto PRE-CREATION > src/state/leveldb.cpp PRE-CREATION > src/state/state.hpp PRE-CREATION > src/state/zookeeper.cpp PRE-CREATION > src/messages/state.hpp PRE-CREATION > src/Makefile.am cd503a8 > src/tests/state_tests.cpp PRE-CREATION > src/zookeeper/group.cpp da2e147 > > Diff: https://reviews.apache.org/r/4981/diff > > > Testing > ------- > > make check > > > Thanks, > > Benjamin > >
