-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/53489/#review155395
-----------------------------------------------------------


Fix it, then Ship it!




Unrelated to this particular change, but can you write up a quick test (doesn't 
need to be committed) to ensure that we don't have infinitely growing future 
chains here, as benh mentioned offline? I never tested this for 
http::Connection, but I suspect we may have a memory growth problem if we open 
a connection and loop sending requests on it (try with both pipe and body).


3rdparty/libprocess/src/http.cpp (line 848)
<https://reviews.apache.org/r/53489/#comment225311>

    Maybe a little comment here?
    
    ```
    // Encodes the request by writing into a pipe, the caller can
    // read the encoded data from the returned read end of the pipe.
    // A pipe is used since the request body can be a pipe and must
    // be read asynchronously.
    ```



3rdparty/libprocess/src/http.cpp (lines 898 - 900)
<https://reviews.apache.org/r/53489/#comment225312>

    Do you want to clear the content length header if they are using a pipe?



3rdparty/libprocess/src/http.cpp (lines 922 - 938)
<https://reviews.apache.org/r/53489/#comment225313>

    How about the following?
    
    ```
      Pipe pipe;
      Pipe::Writer writer = pipe.writer();
      Pipe::Reader reader = pipe.reader();
      
      // Write the head of the request.
      writer.write(out.str());
    
      switch (request.type) {
        case Request::BODY:
          writer.write(request.body);
          writer.close();
          break;
        case Request::PIPE:
          _encode(request.reader.get(), writer);
          break;
      }
      
      return pipe.reader();
    ```
    
    The switch without a default will have a compile time error if we miss any 
types.



3rdparty/libprocess/src/http.cpp (lines 951 - 966)
<https://reviews.apache.org/r/53489/#comment225315>

    Hm.. seems we do not need the string stream in the EOF case:
    
    ```
          if (chunk->empty()) {
            // EOF case.
            writer.write("0\r\n\r\n");
            writer.close();
            return;
          }
          
          std::ostringstream out;
          out << std::hex << chunk.get().size() << "\r\n";
          out << chunk.get();
          out << "\r\n";
          
          writer.write(out.str());
          _encode(reader, writer);
    ```



3rdparty/libprocess/src/http.cpp (lines 1013 - 1017)
<https://reviews.apache.org/r/53489/#comment225301>

    Seems inconsistent to CHECK the reader being some but return Failure for 
the body being some, how about returning Failure for both?



3rdparty/libprocess/src/http.cpp (lines 1019 - 1020)
<https://reviews.apache.org/r/53489/#comment225304>

    How about:
    
    ```
    if (request.headers.contains("Content-Length")) {
      return Failure(...);
    }
    ```



3rdparty/libprocess/src/http.cpp (lines 1034 - 1036)
<https://reviews.apache.org/r/53489/#comment225305>

    I don't think you need the mutable here anymore. Also, how about:
    
    ```
    return _send(socket_, encode(request));
    ```


- Benjamin Mahler


On Nov. 4, 2016, 5:55 p.m., Anand Mazumdar wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/53489/
> -----------------------------------------------------------
> 
> (Updated Nov. 4, 2016, 5:55 p.m.)
> 
> 
> Review request for mesos and Benjamin Mahler.
> 
> 
> Bugs: MESOS-6466
>     https://issues.apache.org/jira/browse/MESOS-6466
> 
> 
> Repository: mesos
> 
> 
> Description
> -------
> 
> This required modifications to the `encode()` method to return
> a `Pipe::Reader` instead of the request body. The `send()` then
> reads from this pipe to send the request via the socket.
> 
> 
> Diffs
> -----
> 
>   3rdparty/libprocess/src/http.cpp b5ddac9f1970358f8232a481431507242052d294 
> 
> Diff: https://reviews.apache.org/r/53489/diff/
> 
> 
> Testing
> -------
> 
> make check
> 
> 
> Thanks,
> 
> Anand Mazumdar
> 
>

Reply via email to