You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@mesos.apache.org by bm...@apache.org on 2018/09/05 20:03:39 UTC
[mesos] branch master updated: Set 'Connection: close' in the
master's streaming API responses.
This is an automated email from the ASF dual-hosted git repository.
bmahler pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/mesos.git
The following commit(s) were added to refs/heads/master by this push:
new c1cb3ca Set 'Connection: close' in the master's streaming API responses.
c1cb3ca is described below
commit c1cb3ca387893b942ed71abfe3e51a7ea7cdc6b3
Author: Benjamin Mahler <bm...@apache.org>
AuthorDate: Tue Aug 28 18:22:02 2018 -0700
Set 'Connection: close' in the master's streaming API responses.
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.
Review: https://reviews.apache.org/r/68553
---
src/master/http.cpp | 29 +++++++++++++++++++++++++++++
1 file changed, 29 insertions(+)
diff --git a/src/master/http.cpp b/src/master/http.cpp
index e074a93..0ac3475 100644
--- a/src/master/http.cpp
+++ b/src/master/http.cpp
@@ -400,6 +400,20 @@ Future<Response> Master::Http::subscribe(
Pipe pipe;
OK ok;
+ // Since the response is infinite, set the 'Connection: close'
+ // header to help indicate to intermediaries (e.g. load
+ // balancers, proxies) that the connection SHOULD NOT be
+ // re-used. Some intermediaries leave the connection to the
+ // server open when a client disconnects in order to re-use
+ // the connection as an optimization. In these cases, the
+ // subscribers do not get removed when the end client
+ // disconnects!
+ //
+ // TODO(bmahler): Libprocess currently doesn't close the
+ // the connection based on a handler setting this header,
+ // but it doesn't matter here since the response is infinite.
+ ok.headers["Connection"] = "close";
+
ok.headers["Content-Type"] = stringify(contentType);
ok.type = Response::PIPE;
ok.reader = pipe.reader();
@@ -581,6 +595,21 @@ Future<Response> Master::Http::scheduler(
Pipe pipe;
OK ok;
+
+ // Since the response is infinite, set the 'Connection: close'
+ // header to help indicate to intermediaries (e.g. load
+ // balancers, proxies) that the connection SHOULD NOT be
+ // re-used. Some intermediaries leave the connection to the
+ // server open when a client disconnects in order to re-use
+ // the connection as an optimization. In these cases, the
+ // scheduler would not get removed when it disconnects from
+ // the intermediary!
+ //
+ // TODO(bmahler): Libprocess currently doesn't close the
+ // the connection based on a handler setting this header,
+ // but it doesn't matter here since the response is infinite.
+ ok.headers["Connection"] = "close";
+
ok.headers["Content-Type"] = stringify(acceptType);
ok.type = Response::PIPE;