Correctly terminate HTTP server #13501

promag · 2018-06-18T22:48:34Z

Fixes #11777. Replaces #13492.

This PR tracks current HTTP connections in order to disable reading on shutdown while allowing all remaining events to process. This allows the event loop to exit gracefully.

This happens in the test framework because the RPC client never closes the connection to the node — the same connection is used for all RPC to that node — even when stop is called.

promag · 2018-06-18T22:51:27Z

This is an alternative to #13492 that doesn't require bumping the minimum libevent2 version. This was submitted in a different branch to keep the other version available.

To test apply

diff --git a/src/rpc/server.cpp b/src/rpc/server.cpp
index 10040b125..57dad383c 100644
--- a/src/rpc/server.cpp
+++ b/src/rpc/server.cpp
@@ -236,6 +236,7 @@ UniValue stop(const JSONRPCRequest& jsonRequest)
     // Event loop will exit after current HTTP requests have been handled, so
     // this reply will get back to the client.
     StartShutdown();
+    MilliSleep(2000);
     return "Bitcoin server stopping";
 }

and then

bitcoind -regtest
bitcoin-cli -regtest stop

ken2812221 · 2018-06-18T23:47:21Z

That event_base_loopexit is still requied though.

promag · 2018-06-19T07:35:26Z

No, it shouldn't be. As soon as there are no more active or pending events, the event loop should exit.

promag · 2018-06-19T15:16:20Z

Updated.

promag · 2018-06-21T13:21:12Z

@ken2812221 care to review?

ken2812221 · 2018-06-21T14:46:51Z

Looks like shutdown would take more time, it takes 30 mins to complete tests on travis, I would rather reopen #13485

promag · 2018-06-23T20:37:40Z

@ken2812221 I'll try to reproduce.

maflcko · 2018-08-08T21:52:45Z

Going to close and reopen, to get a fresh travis run.

Previous run: https://travis-ci.org/bitcoin/bitcoin/builds/394134101

maflcko · 2018-08-08T21:53:16Z

New run: https://travis-ci.org/bitcoin/bitcoin/builds/413803664

Hmm.. Still takes longer than on master, I think

promag · 2018-08-08T21:59:27Z

Thanks @MarcoFalke.

DrahtBot · 2018-08-09T05:05:22Z

The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

Conflicts

No conflicts as of last run.

promag · 2018-08-12T00:51:13Z

Tried to change client and server timeouts and looks like it terminates earlier. This indicates that either the client or server are not terminating gracefully.

laanwj · 2018-10-24T16:45:48Z

src/httpserver.cpp

@@ -14,6 +14,7 @@
 #include <ui_interface.h>

 #include <memory>
+#include <set>


unordered_set? there's no traversing here

IIRC for small collections std::set is preferable. I can change if that sounds better to you.

ryanofsky · 2018-11-01T18:16:42Z

src/httpserver.cpp

        threadHTTP.join();
+        // Process remaining events.
+        event_base_dispatch(eventBase);


The changes in this if (eventBase) section don't seem directly related to the other changes in this PR. If I understand the eventlib documentation correctly, the behavior of the new code is identical to previous code except there is no longer a 2 second timeout.

So is the point of this change just cleanup? It seems like it might be safer to keep the 2 second timeout.

This is necessary in order to have a clean event loop quit, which means all active events processed and there's no pending events. In some cases (long response/slow client) the timeout can cause errors on the client side because the client receives an unexpected connection close.

Ideally it would be enough:

// Wait the event loop to quit threadHTTP.join();

but in windows only this works (sorry I don't know why):

// Wait the event loop to quit in *this* thread event_base_loopbreak(eventBase); threadHTTP.join(); // Process remaining events. event_base_dispatch(eventBase);

This is necessary in order to have a clean event loop quit

It seems like only the part of this change needed to exit cleanly is removing the racy event_base_loopexit added in #11006. Aside from that, it looks like the previous code would also exit cleanly, unless it took longer than 2 seconds.

If the 2 second timeout causes problems, maybe it could be increased, but it doesn't seem like seem like a great idea to me to delay shutdown forever writing data to clients. It also seems nicer that the previous code didn't need an inexplicable windows workaround.

On the other hand, if we really do want to wait forever here instead of timing out, it would be good to delete the std::future/std::packaged_task code added in 755aa05, since now it is sitting there unused.

ryanofsky · 2018-11-01T18:21:09Z

src/httpserver.cpp

+        LOCK(g_http_connections_cs);
+        for (evhttp_connection* conn : g_http_connections) {
+            bufferevent* bev = evhttp_connection_get_bufferevent(conn);
+            if (bev) bufferevent_disable(bev, EV_READ);


Is checking bev just defensive here? Would it ever be expected to be null? It'd be good to have a sentence or shorter comment here to suggest what this does.

No I don't think it can be null, but I'll check libevent code. This "protection" is already on master and I followed it.

ryanofsky · 2018-11-01T18:22:36Z

src/httpserver.cpp

+    {
+        LOCK(g_http_connections_cs);
+        evhttp_connection* conn = evhttp_request_get_connection(req);
+        if (g_http_connections.insert(conn).second) {


Confused by the check. Would this ever be false? Short comment here would be helpful.

One connection can carry multiple request/response pairs.

Won't this be buggy if a client opens a connection but doesn't send a complete request before the server starts to shut down? In that case this code won't get called, so the connection pointer will never be added to g_http_connections, so event_base_dispatch would never return, and bitcoind would hang forever on shutdown.

I don't see a way to be notified directly about new connections, so maybe there is nothing we can do about this, but it seems worth commenting about if there isn't a better approach or workaround.

@ryanofsky tried the following:

bitcoind -regtest nc localhost 18443 bitcoin-cli -regtest stop

at this point the server waits until it timeouts the request (by default 30 seconds).

If a request is sent before the timeout the result is:

POST / HTTP/1.1 Authorization: Basic ... Content-Type: application/json Content-Length: 44 {"jsonrpc": "2.0","method":"help","id":123} HTTP/1.1 503 Service Unavailable Content-Type: text/html Connection: close Date: Mon, 05 Nov 2018 11:58:34 GMT Content-Length: 110 <HTML><HEAD> <TITLE>503 Service Unavailable</TITLE> </HEAD><BODY> <H1>Service Unavailable</H1> </BODY></HTML>

If we consider that stop RPC triggers a graceful shutdown then this LGTM.

src/httpserver.cpp

ryanofsky · 2018-11-01T19:01:00Z

src/httpserver.cpp

@@ -457,21 +475,21 @@ void StopHTTPServer()
        delete workQueue;
        workQueue = nullptr;
    }
+    {
+        LogPrint(BCLog::HTTP, "Disabling reading on current connections\n");


Can you add a comment about what the effect of disabling reading on the current connections is?

If this just disables reading and doesn't close the connections or interrupt pending writes, it seems like shutdown code could potentially get stuck forever (if a client isn't reading and there is a pending write and data is backed up).

So the event base quits when there are no active or pending events. Writing the response is an active event which will go away at the end. Reading can be a pending event (for instance, the client sends stop RPC but keeps the connection open — which happens in the functional tests) so that will prevent the base to quit automatically.

Thanks for explaining, but I keep rereading this and coming away confused, because it is leaving out a lot of specifics. I think the following would be clearer if it is accurate:

// Disable read events so the event loop is able to exit even if there are // open connections. (The preceding InterruptHTTPServer call stops accepting new // connections and new requests on existing connections, but does not close // existing connections.) // // Leave write events enabled because there may still be response data waiting // to be written, and we want to avoid sending incomplete responses.

ryanofsky · 2018-11-01T19:09:48Z

src/httpserver.cpp

@@ -586,11 +604,10 @@ void HTTPRequest::WriteReply(int nStatus, const std::string& strReply)
        // workaround above.
        if (event_get_version_number() >= 0x02010600 && event_get_version_number() < 0x02020001) {
            evhttp_connection* conn = evhttp_request_get_connection(req_copy);
-            if (conn) {
+            LOCK(g_http_connections_cs);
+            if (conn && g_http_connections.count(conn)) {


Comment above "Re-enable reading..." is out of date, or at least incomplete now, and would be good to update.

I think I need to look more into the workaround here, but it's not clear to me why this no longer enables write events during shutdown (or what the effect of that is). Hopefully it doesn't mean that a pending writes would never complete...

Writes are always enabled and there is no reason to enable reading if g_http_connections.count(conn) == 0.

I think it would be helpful to update "Re-enable reading" to "Re-enable reading (unless g_http_connections has been cleared and the server is shutting down)", because I think it's hard to see otherwise how g_http_connections.count is relevant in this context.

meshcollider · 2018-11-01T19:37:09Z

Concept ACK

promag · 2018-11-01T23:16:04Z

@ryanofsky thanks for the review.

jnewbery

Tested ACK d145150. I'm not a libevent expert, so I can't review the API calls, but the changes look reasonable to me, and the test suite runs fine locally for me.

The minimum version of libevent officially supported is 2.0.22 (https://github.com/bitcoin/bitcoin/blob/750415701cb1c9e4cc717be7c810a054dbc2ead0/doc/dependencies.md). I've tested this on libevent 2.0.21. We should make sure that this gets tested on other versions of libevent.

Commits should be squashed prior to merge.

jnewbery · 2018-11-02T18:47:35Z

src/httpserver.cpp

-        // master that appears to be solved, so in the future that solution
-        // could be used again (if desirable).
-        // (see discussion in https://github.com/bitcoin/bitcoin/pull/6990)
-        if (threadResult.valid() && threadResult.wait_for(std::chrono::milliseconds(2000)) == std::future_status::timeout) {


I believe this is the only use of threadResult. Can you remove it entirely (currently declared at L437 and assigned at L446)

ryanofsky

I think it would help this PR to have a more complete description. I would describe it as follows (feel free to copy any of it if useful).

This PR does three things:

It removes an event_base_loopexit optimization added in #11006 that turns out to cause a race condition described in #13492 (comment), where incomplete HTTP responses are sent to clients on shutdown.
It replaces the #11006 optimization with a new one. Without the optimization from #11006, the HTTP event loop would never exit cleanly if there were any open idle connections to the HTTP server, because it would be stuck waiting for read events on those connections. The new optimization implemented here disables these unnecessary waits on shutdown by calling bufferevent_disable, while still waiting for any pending writes to complete.
It removes a two-second shutdown timeout, and instead will wait an infinite time for HTTP writes to complete. With the optimizations above, the two second timeout isn't strictly necessary, since the loop will no longer wait forever when there are idle connections.

ryanofsky · 2018-11-02T16:41:31Z

src/httpserver.cpp

@@ -457,21 +475,21 @@ void StopHTTPServer()
        delete workQueue;
        workQueue = nullptr;
    }
+    {
+        LogPrint(BCLog::HTTP, "Disabling reading on current connections\n");


Thanks for explaining, but I keep rereading this and coming away confused, because it is leaving out a lot of specifics. I think the following would be clearer if it is accurate:

// Disable read events so the event loop is able to exit even if there are // open connections. (The preceding InterruptHTTPServer call stops accepting new // connections and new requests on existing connections, but does not close // existing connections.) // // Leave write events enabled because there may still be response data waiting // to be written, and we want to avoid sending incomplete responses.

ryanofsky · 2018-11-02T17:29:33Z

src/httpserver.cpp

+    {
+        LOCK(g_http_connections_cs);
+        evhttp_connection* conn = evhttp_request_get_connection(req);
+        if (g_http_connections.insert(conn).second) {


Won't this be buggy if a client opens a connection but doesn't send a complete request before the server starts to shut down? In that case this code won't get called, so the connection pointer will never be added to g_http_connections, so event_base_dispatch would never return, and bitcoind would hang forever on shutdown.

I don't see a way to be notified directly about new connections, so maybe there is nothing we can do about this, but it seems worth commenting about if there isn't a better approach or workaround.

ryanofsky · 2018-11-02T18:21:03Z

src/httpserver.cpp

        threadHTTP.join();
+        // Process remaining events.
+        event_base_dispatch(eventBase);


This is necessary in order to have a clean event loop quit

It seems like only the part of this change needed to exit cleanly is removing the racy event_base_loopexit added in #11006. Aside from that, it looks like the previous code would also exit cleanly, unless it took longer than 2 seconds.

If the 2 second timeout causes problems, maybe it could be increased, but it doesn't seem like seem like a great idea to me to delay shutdown forever writing data to clients. It also seems nicer that the previous code didn't need an inexplicable windows workaround.

On the other hand, if we really do want to wait forever here instead of timing out, it would be good to delete the std::future/std::packaged_task code added in 755aa05, since now it is sitting there unused.

ryanofsky · 2018-11-02T18:49:09Z

src/httpserver.cpp

@@ -586,11 +604,10 @@ void HTTPRequest::WriteReply(int nStatus, const std::string& strReply)
        // workaround above.
        if (event_get_version_number() >= 0x02010600 && event_get_version_number() < 0x02020001) {
            evhttp_connection* conn = evhttp_request_get_connection(req_copy);
-            if (conn) {
+            LOCK(g_http_connections_cs);
+            if (conn && g_http_connections.count(conn)) {


I think it would be helpful to update "Re-enable reading" to "Re-enable reading (unless g_http_connections has been cleared and the server is shutting down)", because I think it's hard to see otherwise how g_http_connections.count is relevant in this context.

promag · 2018-11-06T15:19:41Z

After more digging in libevent source code I've realized that sending the header Connection: close is the correct way to trigger the connection close. Verified that this behavior exists since 2.0.22, see https://github.com/libevent/libevent/blob/c51b159cff9f5e86696f5b9a4c6f517276056258/http.c#L472.

It is also unnecessary to keep track of connections as evhttp already handles that.

laanwj · 2018-11-06T16:10:10Z

sending the header Connection: close is the correct way to trigger the connection close

That only signals to the client that the connection should be closed (e.g. no connection reuse), it doesn't actually trigger a close from our side.
(or does it? I'm confused now; at the least it doesn't provide a guarantee that the connection will be closed any time soon, only after the request fully finished)

promag · 2018-11-06T16:26:38Z

From testing it does, see https://github.com/libevent/libevent/blob/c51b159cff9f5e86696f5b9a4c6f517276056258/http.c#L784-L786.

Even with a non-http client, like nc, when I send that header the server will then close the
connection.

28479f9 qa: Test bitcond shutdown (João Barbosa) 8d3f46e http: Remove timeout to exit event loop (João Barbosa) e98a9ee http: Remove unnecessary event_base_loopexit call (João Barbosa) 6b13580 http: Unlisten sockets after all workers quit (João Barbosa) 18e9685 http: Send "Connection: close" header if shutdown is requested (João Barbosa) 02e1e4e rpc: Add wait argument to stop (João Barbosa) Pull request description: Fixes #11777. Reverts #11006. Replaces #13501. With this change the HTTP server will exit gracefully, meaning that all requests will finish processing and sending the response, even if this means to wait more than 2 seconds (current time allowed to exit the event loop). Another small change is that connections are accepted even when the server is stopping, but HTTP requests are rejected. This can be improved later, especially if chunked replies are implemented. Briefly, before this PR, this is the order or events when a request arrives (RPC `stop`): 1. `bufferevent_disable(..., EV_READ)` 2. `StartShutdown()` 3. `evhttp_del_accept_socket(...)` 4. `ThreadHTTP` terminates (event loop exits) because there are no active or pending events thanks to 1. and 3. 5. client doesn't get the response thanks to 4. This can be verified by applying ```diff // Event loop will exit after current HTTP requests have been handled, so // this reply will get back to the client. StartShutdown(); + MilliSleep(2000); return "Bitcoin server stopping"; } ``` and checking the log output: ``` Received a POST request for / from 127.0.0.1:62443 ThreadRPCServer method=stop user=__cookie__ Interrupting HTTP server ** Exited http event loop Interrupting HTTP RPC server Interrupting RPC tor: Thread interrupt Shutdown: In progress... torcontrol thread exit Stopping HTTP RPC server addcon thread exit opencon thread exit Unregistering HTTP handler for / (exactmatch 1) Unregistering HTTP handler for /wallet/ (exactmatch 0) Stopping RPC RPC stopped. Stopping HTTP server Waiting for HTTP worker threads to exit msghand thread exit net thread exit ... sleep 2 seconds ... Waiting for HTTP event thread to exit Stopped HTTP server ``` For this reason point 3. is moved right after all HTTP workers quit. In that moment HTTP replies are queued in the event loop which keeps spinning util all connections are closed. In order to trigger the server side close with keep alive connections (implicit in HTTP/1.1) the header `Connection: close` is sent if shutdown was requested. This can be tested by ``` bitcoind -regtest nc localhost 18443 POST / HTTP/1.1 Authorization: Basic ... Content-Type: application/json Content-Length: 44 {"jsonrpc": "2.0","method":"stop","id":123} ``` Summing up, this PR: - removes explicit event loop exit — event loop exits once there are no active or pending events - changes the moment the listening sockets are removed — explained above - sends header `Connection: close` on active requests when shutdown was requested which is relevant when it's a persistent connection (default in HTTP 1.1) — libevent is aware of this header and closes the connection gracefully - removes event loop explicit break after 2 seconds timeout Tree-SHA512: 4dac1e86abe388697c1e2dedbf31fb36a394cfafe5e64eadbf6ed01d829542785a8c3b91d1ab680d3f03f912d14fc87176428041141441d25dcb6c98a1e069d8

28479f9 qa: Test bitcond shutdown (João Barbosa) 8d3f46e http: Remove timeout to exit event loop (João Barbosa) e98a9ee http: Remove unnecessary event_base_loopexit call (João Barbosa) 6b13580 http: Unlisten sockets after all workers quit (João Barbosa) 18e9685 http: Send "Connection: close" header if shutdown is requested (João Barbosa) 02e1e4e rpc: Add wait argument to stop (João Barbosa) Pull request description: Fixes bitcoin#11777. Reverts bitcoin#11006. Replaces bitcoin#13501. With this change the HTTP server will exit gracefully, meaning that all requests will finish processing and sending the response, even if this means to wait more than 2 seconds (current time allowed to exit the event loop). Another small change is that connections are accepted even when the server is stopping, but HTTP requests are rejected. This can be improved later, especially if chunked replies are implemented. Briefly, before this PR, this is the order or events when a request arrives (RPC `stop`): 1. `bufferevent_disable(..., EV_READ)` 2. `StartShutdown()` 3. `evhttp_del_accept_socket(...)` 4. `ThreadHTTP` terminates (event loop exits) because there are no active or pending events thanks to 1. and 3. 5. client doesn't get the response thanks to 4. This can be verified by applying ```diff // Event loop will exit after current HTTP requests have been handled, so // this reply will get back to the client. StartShutdown(); + MilliSleep(2000); return "Bitcoin server stopping"; } ``` and checking the log output: ``` Received a POST request for / from 127.0.0.1:62443 ThreadRPCServer method=stop user=__cookie__ Interrupting HTTP server ** Exited http event loop Interrupting HTTP RPC server Interrupting RPC tor: Thread interrupt Shutdown: In progress... torcontrol thread exit Stopping HTTP RPC server addcon thread exit opencon thread exit Unregistering HTTP handler for / (exactmatch 1) Unregistering HTTP handler for /wallet/ (exactmatch 0) Stopping RPC RPC stopped. Stopping HTTP server Waiting for HTTP worker threads to exit msghand thread exit net thread exit ... sleep 2 seconds ... Waiting for HTTP event thread to exit Stopped HTTP server ``` For this reason point 3. is moved right after all HTTP workers quit. In that moment HTTP replies are queued in the event loop which keeps spinning util all connections are closed. In order to trigger the server side close with keep alive connections (implicit in HTTP/1.1) the header `Connection: close` is sent if shutdown was requested. This can be tested by ``` bitcoind -regtest nc localhost 18443 POST / HTTP/1.1 Authorization: Basic ... Content-Type: application/json Content-Length: 44 {"jsonrpc": "2.0","method":"stop","id":123} ``` Summing up, this PR: - removes explicit event loop exit — event loop exits once there are no active or pending events - changes the moment the listening sockets are removed — explained above - sends header `Connection: close` on active requests when shutdown was requested which is relevant when it's a persistent connection (default in HTTP 1.1) — libevent is aware of this header and closes the connection gracefully - removes event loop explicit break after 2 seconds timeout Tree-SHA512: 4dac1e86abe388697c1e2dedbf31fb36a394cfafe5e64eadbf6ed01d829542785a8c3b91d1ab680d3f03f912d14fc87176428041141441d25dcb6c98a1e069d8

28479f9 qa: Test bitcond shutdown (João Barbosa) 8d3f46e http: Remove timeout to exit event loop (João Barbosa) e98a9ee http: Remove unnecessary event_base_loopexit call (João Barbosa) 6b13580 http: Unlisten sockets after all workers quit (João Barbosa) 18e9685 http: Send "Connection: close" header if shutdown is requested (João Barbosa) 02e1e4e rpc: Add wait argument to stop (João Barbosa) Pull request description: Fixes bitcoin#11777. Reverts bitcoin#11006. Replaces bitcoin#13501. With this change the HTTP server will exit gracefully, meaning that all requests will finish processing and sending the response, even if this means to wait more than 2 seconds (current time allowed to exit the event loop). Another small change is that connections are accepted even when the server is stopping, but HTTP requests are rejected. This can be improved later, especially if chunked replies are implemented. Briefly, before this PR, this is the order or events when a request arrives (RPC `stop`): 1. `bufferevent_disable(..., EV_READ)` 2. `StartShutdown()` 3. `evhttp_del_accept_socket(...)` 4. `ThreadHTTP` terminates (event loop exits) because there are no active or pending events thanks to 1. and 3. 5. client doesn't get the response thanks to 4. This can be verified by applying ```diff // Event loop will exit after current HTTP requests have been handled, so // this reply will get back to the client. StartShutdown(); + MilliSleep(2000); return "Bitcoin server stopping"; } ``` and checking the log output: ``` Received a POST request for / from 127.0.0.1:62443 ThreadRPCServer method=stop user=__cookie__ Interrupting HTTP server ** Exited http event loop Interrupting HTTP RPC server Interrupting RPC tor: Thread interrupt Shutdown: In progress... torcontrol thread exit Stopping HTTP RPC server addcon thread exit opencon thread exit Unregistering HTTP handler for / (exactmatch 1) Unregistering HTTP handler for /wallet/ (exactmatch 0) Stopping RPC RPC stopped. Stopping HTTP server Waiting for HTTP worker threads to exit msghand thread exit net thread exit ... sleep 2 seconds ... Waiting for HTTP event thread to exit Stopped HTTP server ``` For this reason point 3. is moved right after all HTTP workers quit. In that moment HTTP replies are queued in the event loop which keeps spinning util all connections are closed. In order to trigger the server side close with keep alive connections (implicit in HTTP/1.1) the header `Connection: close` is sent if shutdown was requested. This can be tested by ``` bitcoind -regtest nc localhost 18443 POST / HTTP/1.1 Authorization: Basic ... Content-Type: application/json Content-Length: 44 {"jsonrpc": "2.0","method":"stop","id":123} ``` Summing up, this PR: - removes explicit event loop exit — event loop exits once there are no active or pending events - changes the moment the listening sockets are removed — explained above - sends header `Connection: close` on active requests when shutdown was requested which is relevant when it's a persistent connection (default in HTTP 1.1) — libevent is aware of this header and closes the connection gracefully - removes event loop explicit break after 2 seconds timeout Tree-SHA512: 4dac1e86abe388697c1e2dedbf31fb36a394cfafe5e64eadbf6ed01d829542785a8c3b91d1ab680d3f03f912d14fc87176428041141441d25dcb6c98a1e069d8 # Conflicts: # src/rpc/client.cpp # src/rpc/server.cpp # test/functional/feature_shutdown.py # test/functional/test_framework/test_framework.py

fanquake added the RPC/REST/ZMQ label Jun 18, 2018

promag force-pushed the 2018-06-loopexit branch from c91b202 to f98faf7 Compare June 19, 2018 14:34

promag mentioned this pull request Jun 19, 2018

Fix reply not sent when event loop terminates prematurely #13492

Closed

maflcko closed this Aug 8, 2018

maflcko reopened this Aug 8, 2018

DrahtBot mentioned this pull request Aug 9, 2018

Ensure that http event loop is empty before the loop exit #13485

Closed

promag force-pushed the 2018-06-loopexit branch from f98faf7 to c15a204 Compare August 12, 2018 00:23

promag force-pushed the 2018-06-loopexit branch 2 times, most recently from 85fb361 to 1227f6a Compare August 14, 2018 00:08

promag force-pushed the 2018-06-loopexit branch 2 times, most recently from 746fd16 to 51a5959 Compare August 17, 2018 00:10

laanwj reviewed Oct 24, 2018

View reviewed changes

ryanofsky reviewed Nov 1, 2018

View reviewed changes

promag added 4 commits November 1, 2018 23:07

rename to g_http_connections_mutex

b28ed68

add comment

a826493

add comment

ca43f55

remove unnecessary check

d145150

jnewbery reviewed Nov 2, 2018

View reviewed changes

ryanofsky reviewed Nov 2, 2018

View reviewed changes

promag closed this Nov 6, 2018

promag mentioned this pull request Nov 6, 2018

http: Fix HTTP server shutdown #14670

Merged

promag changed the title ~~Correctly terminate HTTP server~~ ~~Correctly~~ terminate HTTP server Nov 6, 2018

bitcoin locked as resolved and limited conversation to collaborators Sep 8, 2021

~~Correctly~~ terminate HTTP server #13501

~~Correctly~~ terminate HTTP server #13501

Uh oh!

Conversation

promag commented Jun 18, 2018 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

promag commented Jun 18, 2018 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ken2812221 commented Jun 18, 2018

Uh oh!

promag commented Jun 19, 2018

Uh oh!

promag commented Jun 19, 2018

Uh oh!

promag commented Jun 21, 2018

Uh oh!

ken2812221 commented Jun 21, 2018 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

promag commented Jun 23, 2018

Uh oh!

maflcko commented Aug 8, 2018

Uh oh!

maflcko commented Aug 8, 2018 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

promag commented Aug 8, 2018

Uh oh!

DrahtBot commented Aug 9, 2018 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Conflicts

Uh oh!

promag commented Aug 12, 2018

Uh oh!

laanwj Oct 24, 2018 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

promag Nov 1, 2018 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ryanofsky Nov 1, 2018 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

promag Nov 5, 2018 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

meshcollider commented Nov 1, 2018

Correctly terminate HTTP server #13501

Correctly terminate HTTP server #13501

promag commented Jun 18, 2018 •

edited

Loading

promag commented Jun 18, 2018 •

edited

Loading

ken2812221 commented Jun 21, 2018 •

edited

Loading

maflcko commented Aug 8, 2018 •

edited

Loading

DrahtBot commented Aug 9, 2018 •

edited

Loading

laanwj Oct 24, 2018 •

edited

Loading

promag Nov 1, 2018 •

edited

Loading

ryanofsky Nov 1, 2018 •

edited

Loading

promag Nov 5, 2018 •

edited

Loading

laanwj commented Nov 6, 2018 •

edited

Loading