mesos-reviews mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Vinod Kone" <vinodk...@gmail.com>
Subject Re: Review Request 41283: Introduced an Executor Library based on the new executor HTTP API.
Date Thu, 21 Jan 2016 19:33:01 GMT

-----------------------------------------------------------
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
> 
>


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message