----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/4981/#review7529 -----------------------------------------------------------
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? - John 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 > >
