http: Fix HTTP server shutdown #14670

promag · 2018-11-06T15:04:48Z

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

bufferevent_disable(..., EV_READ)
StartShutdown()
evhttp_del_accept_socket(...)
ThreadHTTP terminates (event loop exits) because there are no active or pending events thanks to 1. and 3.
client doesn't get the response thanks to 4.

This can be verified by applying

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

jnewbery · 2018-11-06T15:07:20Z

@promag can you explain how this is different from #13501 and what the reasoning was for closing that PR?

maflcko · 2018-11-06T15:08:57Z

This is now the trillionth attempt in fixing the issue. Could you provide some rationale how this is different from the other approaches and why it should be preferred over the other ones?

ryanofsky · 2018-11-06T15:38:28Z

This is simpler than #13501, and if it works I think it is preferable. Instead of trying to wait for all reply data to be sent before stopping the event loop and calling evhttp_free, it lets evhttp_free worry about this and stop the event loop itself. Assuming http_free does the right thing, this is a cleaner and less invasive.

I am curious what exactly the behavior of evhttp_free is. For example if we are in the middle of sending a huge reply to a slow client, and the server is shut down, how long does this wait (if it waits at all) to send all the data before shutting down? IIUC #13501 would wait as long as it took, and currently we wait for 2 seconds.

ryanofsky · 2018-11-06T16:07:37Z

It seems like evhttp_free just immediately calls shutdown and close on all open connections, so I would expect this change not to always fix #11777.

https://github.com/libevent/libevent/blob/9afe7a6c12c112a6cbc49cf1bd684781275b2579/http.c#L1243
https://github.com/libevent/libevent/blob/9afe7a6c12c112a6cbc49cf1bd684781275b2579/http.c#L3721

But maybe the WriteHeader("Connection", "close") call added to HTTPRequest::WriteReply improves things in some way, so even if there is a race condition, it won't trigger in practice?

DrahtBot · 2018-11-06T17:57:15Z

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

Conflicts

Reviewers, this pull request conflicts with the following ones:

#14726 (Use RPCHelpMan for all RPCs by MarcoFalke)

If you consider this pull request important, please also help to review the conflicting pull requests. Ideally, start with the one that should be merged first.

promag · 2018-11-07T03:19:02Z

@ryanofsky right, can't call evhttp_free with ongoing requests.

Updated code and PR description, should be more clear of the current problem and the approach used.

promag · 2018-11-07T09:33:08Z

Split in multiple commits for easy review.

It can be arguable to remove the timeout but IMO it's safe because:

if an HTTP worker is with a long task then calling event_base_loopbreak is no good
active connections will timeout and close if no request/response happens (30 seconds by default).

This can be observed by:

bitcoind -regtest
time nc localhost 18443
bitcoin-cli -regtest stop
nc localhost 18443  0.00s user 0.01s system 0% cpu 30.025 total
                                                   ^^^^^^

The only way to improve this in a correct way is to lower the connection timeout (that I know of)

ken2812221

Concept ACK.

src/httpserver.cpp

ryanofsky · 2018-11-07T15:12:24Z

Can you update the PR description to describe the change in external behavior instead of diving immediately into details of the code?

It would also help if each individual commit stated how it changes behavior, and why the change makes sense by itself or in conjunction with other changes.

promag · 2018-11-07T16:56:17Z

describe the change in external behavior

@ryanofsky sorry I don't understand what you mean with external behavior.

and why the change makes sense by itself or in conjunction with other changes

I think I did?

It would also help if each individual commit stated how it changes behavior

Will do.

maflcko · 2018-11-07T17:00:20Z

I think external behaviour means the behaviour users or json-rpc-wrapper libraries see.

ryanofsky · 2018-11-07T17:26:27Z

What will happen if bitcoin is in the middle of sending a large response to a slow client and it gets shutdown? Will it try to send as much as of the reply as possible but give up after a timeout? Will it stop sending immediately? Will it wait forever? Previous versions of this PR have done a bunch of different things, so what externally observable changes is this PR is intending to make? I think this would be the most useful information to know and include in the description.

promag · 2018-11-07T22:52:42Z

@ryanofsky still testing but I believe it waits until HTTP request finishes or timeouts due to inactivity on the connection. In detail this means:

completes reading the request headers and body
worker computes full response and adds event to send the response
the response is sent and then the connection is finally closed
at this point, if it's the last connection, the event loop has no registered events and exists.

Updated commits and PR description. ~~Added @ken2812221 suggestion.~~

laanwj · 2018-11-20T09:24:30Z

Can you update the PR description to describe the change in external behavior instead of diving immediately into details of the code?

Also, can we please add a test that fails without this, but passes with it? That's the best way to "prove" that this fixes something.

promag · 2018-11-20T18:16:04Z

ef7c54c1e - rpc: Add wait argument to stop
8589891ea - http: Send "Connection: close" header if shutdown is requested
e10898267 - http: Unlisten sockets after all workers quit
b1f241a0f - http: Remove unnecessary event_base_loopexit call
a72fbc8aa - http: Remove timeout to exit event loop
c76cde3c9 - qa: Test shutdown

@laanwj if you build only the marked commits then test test/functional/feature_shutdown.py fails.

test/functional/feature_shutdown.py

promag · 2018-12-14T08:57:50Z

At least it doesn't look. Looks more a race between the thread that runs test_long_call and stop_node — if stop_node runs before then RPC would be unavailable. It seems unlikely because of the 1 second wait but it should be possible considering the probable load.

promag · 2018-12-14T12:00:03Z

Tested the change:

diff --git a/test/functional/feature_shutdown.py b/test/functional/feature_shutdown.py
index 5a0c88546..b0df81736 100755
--- a/test/functional/feature_shutdown.py
+++ b/test/functional/feature_shutdown.py
@@ -7,8 +7,11 @@
 from test_framework.test_framework import BitcoinTestFramework
 from test_framework.util import assert_equal, get_rpc_proxy
 from threading import Thread
+from time import sleep
+

 def test_long_call(node):
+    sleep(1)
     block = node.waitfornewblock()
     assert_equal(block['height'], 0)

which gives the following error:

ConnectionRefusedError: [Errno 61] Connection refused

Then on top of that:

@@ -20,6 +23,8 @@ class ShutdownTest(BitcoinTestFramework):

     def run_test(self):
         node = get_rpc_proxy(self.nodes[0].url, 1, timeout=600, coveragedir=self.nodes[0].coverage_dir)
+        # force connection establishment
+        node.getblockcount()

the error is now

test_framework.authproxy.JSONRPCException: non-JSON HTTP response with '503 Service Unavailable' from server (-342)

This could be easily fixed if we had a way to inspect how many RPC workers are running, for instance, by having a getrpcinfo.

Meanwhile this can be "prevented" by adding some relaxation:

@@ -26,6 +26,7 @@ class ShutdownTest(BitcoinTestFramework):
         # force connection establishment
         node.getblockcount()
         Thread(target=test_long_call, args=(node,)).start()
+        sleep(1)

@ken2812221

…rate connections 4412a59 qa: Remove race between connecting and shutdown on separate connections (João Barbosa) Pull request description: Fixes the error #14670 (comment) reported by @ken2812221. There is a race between RPC stop and another concurrent call in the test framework. The connection must be established and the command `waitfornewblock` running before calling `stop`. See also #14670 (comment). Tree-SHA512: 77feb8628d3b9c025ec0cf83565d4d6680cad4fb182fc93a65df8b573f3e799ba4c44e06d9001dd8a375ca0b1ee17f10e66c3902b6256d0ae2acbc64539185d7

Ignore disconnects when stopping node - fixes #367 This is a port of bitcoin/bitcoin#14670 This problem is related to the "stop" RPC call. It turns out that sometimes the node stops before it sends the response. That causes the client to retry the call and lead to "ConnectionRefusedError". I found out that there is a fix in bitcoin repo (in master branch, actually), related to this bug. In the nutshell, this changes removes forced exit of libevent loop, which allows to process all the requests gracefully. Test feature_shutdown.py wasn't ported because it introduces a bug bitcoin/bitcoin#14670 (comment) The "improvement" bitcoin/bitcoin#14958 requires RPC method "getrpcinfo" which isn't ported from the bitcoin codebase yet. There are other floating tests with a similar error (ConnectionRefusedError): fixes #373 fixes #484 fixes #544 Signed-off-by: Dmitry Saveliev <dima@thirdhash.com>

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

@ken2812221

…rate connections Summary: [[https://github.com/bitcoin/bitcoin/pull/14958/files | PR14958]] backport, fixup to D5170 4412a59bfe8228698e5b5bbe8bb21c8e8a70d357 qa: Remove race between connecting and shutdown on separate connections (João Barbosa) Pull request description: Fixes the error bitcoin/bitcoin#14670 (comment) reported by @ken2812221. There is a race between RPC stop and another concurrent call in the test framework. The connection must be established and the command `waitfornewblock` running before calling `stop`. See also bitcoin/bitcoin#14670 (comment). Depends on D5170 and D5173 Test Plan: `ninja check-all` Reviewers: #bitcoin_abc, Fabien Reviewed By: #bitcoin_abc, Fabien Differential Revision: https://reviews.bitcoinabc.org/D5174

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

@ken2812221

…on separate connections 4412a59 qa: Remove race between connecting and shutdown on separate connections (João Barbosa) Pull request description: Fixes the error bitcoin#14670 (comment) reported by @ken2812221. There is a race between RPC stop and another concurrent call in the test framework. The connection must be established and the command `waitfornewblock` running before calling `stop`. See also bitcoin#14670 (comment). Tree-SHA512: 77feb8628d3b9c025ec0cf83565d4d6680cad4fb182fc93a65df8b573f3e799ba4c44e06d9001dd8a375ca0b1ee17f10e66c3902b6256d0ae2acbc64539185d7

@ken2812221

…on separate connections 4412a59 qa: Remove race between connecting and shutdown on separate connections (João Barbosa) Pull request description: Fixes the error bitcoin#14670 (comment) reported by @ken2812221. There is a race between RPC stop and another concurrent call in the test framework. The connection must be established and the command `waitfornewblock` running before calling `stop`. See also bitcoin#14670 (comment). Tree-SHA512: 77feb8628d3b9c025ec0cf83565d4d6680cad4fb182fc93a65df8b573f3e799ba4c44e06d9001dd8a375ca0b1ee17f10e66c3902b6256d0ae2acbc64539185d7

@ken2812221

…on separate connections 4412a59 qa: Remove race between connecting and shutdown on separate connections (João Barbosa) Pull request description: Fixes the error bitcoin#14670 (comment) reported by @ken2812221. There is a race between RPC stop and another concurrent call in the test framework. The connection must be established and the command `waitfornewblock` running before calling `stop`. See also bitcoin#14670 (comment). Tree-SHA512: 77feb8628d3b9c025ec0cf83565d4d6680cad4fb182fc93a65df8b573f3e799ba4c44e06d9001dd8a375ca0b1ee17f10e66c3902b6256d0ae2acbc64539185d7

@ken2812221

…on separate connections 4412a59 qa: Remove race between connecting and shutdown on separate connections (João Barbosa) Pull request description: Fixes the error bitcoin#14670 (comment) reported by @ken2812221. There is a race between RPC stop and another concurrent call in the test framework. The connection must be established and the command `waitfornewblock` running before calling `stop`. See also bitcoin#14670 (comment). Tree-SHA512: 77feb8628d3b9c025ec0cf83565d4d6680cad4fb182fc93a65df8b573f3e799ba4c44e06d9001dd8a375ca0b1ee17f10e66c3902b6256d0ae2acbc64539185d7

@ken2812221

…on separate connections 4412a59 qa: Remove race between connecting and shutdown on separate connections (João Barbosa) Pull request description: Fixes the error bitcoin#14670 (comment) reported by @ken2812221. There is a race between RPC stop and another concurrent call in the test framework. The connection must be established and the command `waitfornewblock` running before calling `stop`. See also bitcoin#14670 (comment). Tree-SHA512: 77feb8628d3b9c025ec0cf83565d4d6680cad4fb182fc93a65df8b573f3e799ba4c44e06d9001dd8a375ca0b1ee17f10e66c3902b6256d0ae2acbc64539185d7

@ken2812221

…on separate connections 4412a59 qa: Remove race between connecting and shutdown on separate connections (João Barbosa) Pull request description: Fixes the error bitcoin#14670 (comment) reported by @ken2812221. There is a race between RPC stop and another concurrent call in the test framework. The connection must be established and the command `waitfornewblock` running before calling `stop`. See also bitcoin#14670 (comment). Tree-SHA512: 77feb8628d3b9c025ec0cf83565d4d6680cad4fb182fc93a65df8b573f3e799ba4c44e06d9001dd8a375ca0b1ee17f10e66c3902b6256d0ae2acbc64539185d7

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 Nov 6, 2018

promag force-pushed the 2018-11-httpserver branch 3 times, most recently from 629f594 to 2b7bfd3 Compare November 7, 2018 02:42

promag force-pushed the 2018-11-httpserver branch 2 times, most recently from 2c99245 to 4155634 Compare November 7, 2018 09:14

ken2812221 reviewed Nov 7, 2018

View reviewed changes

src/httpserver.cpp Show resolved Hide resolved

promag force-pushed the 2018-11-httpserver branch 2 times, most recently from 0fa937b to 1ba3b86 Compare November 7, 2018 22:40

promag force-pushed the 2018-11-httpserver branch from 1ba3b86 to 25bb1c1 Compare November 8, 2018 00:37

promag force-pushed the 2018-11-httpserver branch 3 times, most recently from 9ca7ec6 to ab4f7a0 Compare November 20, 2018 18:15

promag force-pushed the 2018-11-httpserver branch from 048debd to c76cde3 Compare November 20, 2018 21:41

DrahtBot reviewed Nov 20, 2018

View reviewed changes

test/functional/feature_shutdown.py Outdated Show resolved Hide resolved

promag force-pushed the 2018-11-httpserver branch from fee2592 to 92a81ad Compare November 21, 2018 09:37

promag mentioned this pull request Dec 14, 2018

qa: Remove race between connecting and shutdown on separate connections #14958

Merged

promag deleted the 2018-11-httpserver branch December 15, 2018 14:57

ryanofsky mentioned this pull request Feb 1, 2019

tests: Running with --usecli ~5x slower than without #15309

Closed

promag mentioned this pull request Feb 7, 2019

http: Release server before waiting for event base loop exit #15363

Closed

dsaveliev mentioned this pull request Feb 28, 2019

Ignore disconnects when stopping node dtr-org/unit-e#690

Merged

markblundeberg mentioned this pull request Feb 6, 2020

rpc: Fix data race (UB) in InterruptRPC() #14993

Merged

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

http: Fix HTTP server shutdown #14670

http: Fix HTTP server shutdown #14670

Uh oh!

Conversation

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

Uh oh!

Uh oh!

jnewbery commented Nov 6, 2018

Uh oh!

maflcko commented Nov 6, 2018

Uh oh!

ryanofsky commented Nov 6, 2018

Uh oh!

ryanofsky commented Nov 6, 2018

Uh oh!

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

Uh oh!

Conflicts

Uh oh!

promag commented Nov 7, 2018

Uh oh!

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

Uh oh!

Uh oh!

ken2812221 left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

ryanofsky commented Nov 7, 2018

Uh oh!

promag commented Nov 7, 2018

Uh oh!

maflcko commented Nov 7, 2018

Uh oh!

ryanofsky commented Nov 7, 2018

Uh oh!

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

Uh oh!

Uh oh!

laanwj commented Nov 20, 2018

Uh oh!

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

Uh oh!

Uh oh!

Uh oh!

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

Uh oh!

Uh oh!

promag commented Dec 14, 2018

Uh oh!

Uh oh!

promag commented Nov 6, 2018 •

edited

Loading

DrahtBot commented Nov 6, 2018 •

edited

Loading

promag commented Nov 7, 2018 •

edited

Loading

promag commented Nov 7, 2018 •

edited

Loading

promag commented Nov 20, 2018 •

edited

Loading

promag commented Dec 14, 2018 •

edited

Loading