mesos-reviews mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gastón Kleiman <gas...@mesosphere.io>
Subject Re: Review Request 68553: Set 'Connection: close' in the master's streaming API responses.
Date Wed, 05 Sep 2018 03:11:26 GMT

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


Ship it!




We should do the same in the executor API handler.

- Gastón Kleiman


On Aug. 28, 2018, 7:03 p.m., Benjamin Mahler wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/68553/
> -----------------------------------------------------------
> 
> (Updated Aug. 28, 2018, 7:03 p.m.)
> 
> 
> Review request for mesos, Gastón Kleiman and Vinod Kone.
> 
> 
> Bugs: MESOS-9189
>     https://issues.apache.org/jira/browse/MESOS-9189
> 
> 
> Repository: mesos
> 
> 
> Description
> -------
> 
> We've seen some HTTP intermediaries (e.g. ELB) decide to re-use
> connections to mesos as an optimization to avoid re-connection
> overhead. As a result, when the end-client of the streaming API
> disconnects from the intermediary, the intermediary leaves the
> connection to Mesos open in an attempt to re-use the connection
> for another request once the response completes. Mesos then thinks
> that the subscriber never disconnected and the intermediary happily
> continues to read the streaming events even though there's no
> end-client.
> 
> To help indicate to intermediaries that the connection SHOULD NOT
> be re-used, we can set the 'Connection: close' header for streaming
> API responses. It may not be respected (since the language seems to
> be SHOULD NOT), but some intermediaries may respect it and close the
> connection if the end-client disconnects.
> 
> Note that libprocess' http server currently doesn't close the the
> connection based on a handler setting this header, but it doesn't
> matter here since the master's operator / scheduler and agent's
> executor streaming API responses are infinite.
> 
> 
> Diffs
> -----
> 
>   src/master/http.cpp e074a93666d82944774e7b0c3fa32d7021d93c97 
> 
> 
> Diff: https://reviews.apache.org/r/68553/diff/1/
> 
> 
> Testing
> -------
> 
> Manually verified headers make it through:
> 
> ```
> $ telnet 10.0.49.2 5050
> Trying 10.0.49.2...
> Connected to 10.0.49.2.
> Escape character is '^]'.
> POST /master/api/v1 HTTP/1.1
> Content-Type: application/json
> Accept: application/json
> Content-Length: 20
> 
> {"type":"SUBSCRIBE"}
> HTTP/1.1 200 OK
> Transfer-Encoding: chunked
> Content-Type: application/json
> Date: Wed, 29 Aug 2018 01:58:34 GMT
> Connection: close
> 
> 9e
> 154
> {"type":"SUBSCRIBED","subscribed":{"get_state":{"get_tasks":{},"get_executors":{},"get_frameworks":{},"get_agents":{}},"heartbeat_interval_seconds":15.0}}
> 17
> 20
> {"type":"HEARTBEAT"}
> ```
> 
> 
> Thanks,
> 
> Benjamin Mahler
> 
>


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