----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/41283/#review115502 -----------------------------------------------------------
src/executor/executor.cpp (line 170) <https://reviews.apache.org/r/41283/#comment176479> should be a CHECK as this is not expected. src/executor/executor.cpp (lines 198 - 200) <https://reviews.apache.org/r/41283/#comment176477> This should be a CHECK at #190, because this is not expected. src/executor/executor.cpp (line 214) <https://reviews.apache.org/r/41283/#comment176478> Ditto. This should be a CHECK instead. src/executor/executor.cpp (lines 219 - 221) <https://reviews.apache.org/r/41283/#comment176480> why not set these in the initializer list? src/executor/executor.cpp (lines 238 - 259) <https://reviews.apache.org/r/41283/#comment176487> I think it would be a bit clearer to follow if you do something like this ``` if (call.type() == Call::SUBSCRIBE) { // If we are in `CONNECTED` state, subscribe connection should exist. CHECK_SOME(subscribe); _send(call); } else { if (nonSubscribe.isSome()) { // If nonSubscribe connection already exists, use it. _send(call); } else { // Create a new nonSubscribe connection. ... } } ``` src/executor/executor.cpp (line 239) <https://reviews.apache.org/r/41283/#comment176492> what happens if this future is failed or discarded? src/executor/executor.cpp (line 241) <https://reviews.apache.org/r/41283/#comment176493> Don't we have to check here that nonSubscribe is already set? For example, 2 back to back non-subscribe calls might result in 2 non-subscribe connections? src/executor/executor.cpp (line 247) <https://reviews.apache.org/r/41283/#comment176488> log the future's error if it is in error state. src/executor/executor.cpp (line 269) <https://reviews.apache.org/r/41283/#comment176491> Lets comment here that the library is considered connected if we can establish the subscribe connection. Worth mentioning here that non-subscribe calls use a different `nonSubscribe` connection and that its disconnection doesn't change the `state`. src/executor/executor.cpp (line 274) <https://reviews.apache.org/r/41283/#comment176490> what happens if this future is discarded? src/executor/executor.cpp (line 300) <https://reviews.apache.org/r/41283/#comment176673> can we convert `_connected` into a lambda? src/executor/executor.cpp (line 309) <https://reviews.apache.org/r/41283/#comment176675> How is this possible? Can you expand the comment? src/executor/executor.cpp (lines 313 - 314) <https://reviews.apache.org/r/41283/#comment176676> Move this comment down to #327. src/executor/executor.cpp (line 320) <https://reviews.apache.org/r/41283/#comment176678> does this need to be a function? src/executor/executor.cpp (line 323) <https://reviews.apache.org/r/41283/#comment176674> can we convert `_disconnected` to a lambda? src/executor/executor.cpp (lines 376 - 378) <https://reviews.apache.org/r/41283/#comment176680> Can there be more than one oustanding connection attempts at any given time? src/executor/executor.cpp (line 596) <https://reviews.apache.org/r/41283/#comment176687> no need for stringify? src/executor/executor.cpp (line 601) <https://reviews.apache.org/r/41283/#comment176688> can you add a comment on why you do `false` here? src/executor/executor.cpp (line 624) <https://reviews.apache.org/r/41283/#comment176689> Add a comment here (or above where I commented) that the state tracks the `subscribe` connection. Also, do we really need this enum? Can't we just use `subscribe` to figure if we are connected or not? - Vinod Kone On Jan. 20, 2016, 10:11 p.m., Anand Mazumdar wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/41283/ > ----------------------------------------------------------- > > (Updated Jan. 20, 2016, 10:11 p.m.) > > > Review request for mesos, Ben Mahler and Vinod Kone. > > > Bugs: MESOS-3550 > https://issues.apache.org/jira/browse/MESOS-3550 > > > Repository: mesos > > > Description > ------- > > This change introduces the implementation for the executor library. > > This uses the new HTTP Connection interface to ensure calls are properly > pipelined. > > `connected` -> Callback invoked when a TCP connection is established with the > agent for the `Subscribe` call. > `disconnected` -> When the `Subscribe` TCP connection is interrupted possibly > due to an agent restart. > `received` -> When the executor receives events from the agent upon > subscribing. > > > Diffs > ----- > > src/Makefile.am d23e35001078a86775bd9b76baa207ecb9dab7e1 > src/executor/executor.cpp PRE-CREATION > > Diff: https://reviews.apache.org/r/41283/diff/ > > > Testing > ------- > > make check > > > Thanks, > > Anand Mazumdar > >
