Commit Graph

4 Commits

Author SHA1 Message Date
MarcoFalke
6dbc9aba0d Merge #17675: tests: Enable tests which are incorrectly skipped when running test_runner.py --usecli
5ac804a9eb0cdbdcff8b50ecfb736f8793cab805 tests: Use a default of supports_cli=True (instead of supports_cli=False) (practicalswift)
993e38a4e2fa66093314b988dfbe459f46aa5864 tests: Mark functional tests not supporting bitcoin-cli (--usecli) as such (practicalswift)

Pull request description:

  Annotate functional tests supporting `bitcoin-cli` (`--usecli`) as such.

  Prior to this commit 74 tests were unnecessarily skipped when running `test_runner.py --usecli`.

  Before [bitcoin original commit stats]:

  ```
  $ test/functional/test_runner.py --usecli > /dev/null 2>&1
  $ echo $?
  0
  $ test/functional/test_runner.py --usecli 2>&1 | cut -f2 -d'|' | \
      grep -E ' (Passed|Skipped) *$' | sort | uniq -c
        9  ✓ Passed
      126  ○ Skipped
  ```

  After [dash numbers]:

  ```
  $ test/functional/test_runner.py --usecli > /dev/null 2>&1
  $ echo $?
  0
  $ test/functional/test_runner.py --usecli 2>&1 | cut -f2 -d'|' | \
      grep -E ' (Passed|Skipped) *$' | sort | uniq -c
       110  ✓ Passed
       51  ○ Skipped
  ```

  Context: `--usecli` was introduced in f6ade9ce1a

ACKs for top commit:
  laanwj:
    Code review ACK 5ac804a9eb0cdbdcff8b50ecfb736f8793cab805

Tree-SHA512: 249c0b691a74cf201c729df86c3db2b3faefa53b94703941e566943d252c6d14924e935a8da4f592951574235923fbb7cd22612a5e7e02ff6c762c55a2320ca3
2022-06-08 12:35:12 +07:00
Wladimir J. van der Laan
8de8cf33d1 Merge #14958: qa: Remove race between connecting and shutdown on separate connections
4412a59bfe8228698e5b5bbe8bb21c8e8a70d357 qa: Remove race between connecting and shutdown on separate connections (João Barbosa)

Pull request description:

  Fixes the error https://github.com/bitcoin/bitcoin/pull/14670#issuecomment-447255352 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 https://github.com/bitcoin/bitcoin/pull/14670#issuecomment-447304513.

Tree-SHA512: 77feb8628d3b9c025ec0cf83565d4d6680cad4fb182fc93a65df8b573f3e799ba4c44e06d9001dd8a375ca0b1ee17f10e66c3902b6256d0ae2acbc64539185d7
2021-12-26 22:25:14 -05:00
UdjinM6
05ac4dbb45
Dashify few strings (#3214) 2019-11-22 21:13:19 +03:00
Wladimir J. van der Laan
fefe07003b Merge #14670: http: Fix HTTP server shutdown
28479f926f21f2a91bec5a06671c60e5b0c55532 qa: Test bitcond shutdown (João Barbosa)
8d3f46ec3938e2ba17654fecacd1d2629f9915fd http: Remove timeout to exit event loop (João Barbosa)
e98a9eede2fb48ff33a020acc888cbcd83e24bbf http: Remove unnecessary event_base_loopexit call (João Barbosa)
6b13580f4e3842c11abd9b8bee7255fb2472b6fe http: Unlisten sockets after all workers quit (João Barbosa)
18e968581697078c36a3c3818f8906cf134ccadd http: Send "Connection: close" header if shutdown is requested (João Barbosa)
02e1e4eff6cda0bfc24b455a7c1583394cbff6eb 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
2019-10-14 13:45:09 +02:00