> On May 29, 2014, 5:13 p.m., Vinod Kone wrote: > > src/tests/slave_tests.cpp, line 815 > > <https://reviews.apache.org/r/21968/diff/6/?file=597869#file597869line815> > > > > I dont think you need this abstraction. Just advance the clock and make > > sure there is no registration message sent. > > Yifan Gu wrote: > This is where I feel confused, because I found that I could not catch a > ReregisterSlaveMessage, instead, I could only catch the > SlaveReregisteredMessage. > > Yifan Gu wrote: > Updated: > > Hey Vinod, > I have tried to set up a Future<SlaveReregisteredMessage> > slaveReregisteredMessage = FUTURE_PROTOBUF(...). > And tried to test if it's still not ready by > CHECK(slaveReregisteredMessage.isPending()); > But I found that once the FUTURE_PROTOBUF is set up, it will fail if > there is never called regardless if the future object is statisfied or not, > because there is a EXPECT_CALL in FUTURE_MESSAGE in > libprocess/include/gmock.hpp. > > Sorry, I am not familiar with the future stuff, so maybe I missed > something here. It would be awesome if you could give some suggestions! > Thanks! > > Vinod Kone wrote: > I'm guessing you weren't able to catch "ReregisterSlaveMessage" because > you incorrectly set the "from", "to" fields in the FUTURE_PROTOBUF(). > > Regarding using future returned FUTURE_PROTOBUF to test for pending, you > are right it expects to be called once. But you can use the future from > DROP_PROTOBUF without that problem? > > Yifan Gu wrote: > You are right! I made a silly mistake here. I have replaced the > SlaveReregisteredMessage with ReregisterSlaveMessage, Thanks! > > But I tried to use the future returned by DROP_PROTOBUF(), to replace > NO_FUTURE_PROTOBUFS(), and assert that the future is not ready at the end. > But I got the same result as using FUTURE_PROTOBUF(), I think that is because > both FUTURE_PROTOBUF and DROP_PROTOBUF are calling the same > process::FutureMessage() in gmock.hpp. > > Please point me out if I am doing wrong. > > I updated two diff files, r10 is the version using DROP_PROTOBUF(), which > fails the test. > r11 is the version using NO_FUTURE_PROTOBUFS(), but replaced the > SlavereregisteredMessage to ReregisterSlaveMessage. > > Please point me out if I am doing something wrong! Thank you! > >
Ehh, I uploaded the wrong file for r10, so I just added a diff file... - Yifan ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/21968/#review44265 ----------------------------------------------------------- On May 30, 2014, 9:37 p.m., Yifan Gu wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/21968/ > ----------------------------------------------------------- > > (Updated May 30, 2014, 9:37 p.m.) > > > Review request for mesos, Adam B, Niklas Nielsen, and Vinod Kone. > > > Bugs: MESOS-878 > https://issues.apache.org/jira/browse/MESOS-878 > > > Repository: mesos-git > > > Description > ------- > > Added a sentence to check the slave's state in doReliableRegistration() to > make sure that the function returns when the slave's state is TERMINATING. > Also, to write the test, I need to make sure there's no additional > doReliableRegistration() calls, so I added NO_FUTURE_PROTOBUFS() and > NO_FUTURE_MESSAGES() to make sure there's no more SlaveReregisteredMessages. > > > Diffs > ----- > > 3rdparty/libprocess/include/process/gmock.hpp daba7e3 > src/slave/slave.cpp 7fbedb1 > src/tests/mesos.hpp 1b0f358 > src/tests/slave_tests.cpp 80fe3cf > > Diff: https://reviews.apache.org/r/21968/diff/ > > > Testing > ------- > > Slave_tests.cpp:TerminatingSlaveDoesNotReregister. > > > File Attachments > ---------------- > > Using DROP_PROTOBUF() > > https://reviews.apache.org/media/uploaded/files/2014/05/30/7c0e1b69-19c1-4868-865e-d47fbb739585__mesos.diff > > > Thanks, > > Yifan Gu > >
