We seem to have deadlock bugs in our RPC system, most likely inherited from ZEC or BTC.
Since some Hush RPC's take longer (such as anything with Sietch protections), the deadlocks
are more likely to occur. Eventually all RPC slots are used up and no more RPC commands
can be sent to hushd. This is why the "plz_stop" feature was implemented, but that is just
a workaround to restart the server. We must find and fix the root cause.
This rpc will allow us to see when we are getting close to our maximum work queue depth
and hopefully help us learn exactly what is happening.
Any projects which want to use Hush code from now on will need to be licensed as
GPLv3 or we will send the lawyers: https://www.softwarefreedom.org/
Notably, Komodo (KMD) is licensed as GPLv2 and is no longer compatible to receive
code changes, without causing legal issues. MIT projects, such as Zcash, also cannot pull
in changes from the Hush Full Node without permission from The Hush Developers,
which may in some circumstances grant an MIT license on a case-by-case basis.
Fix various thread assertion errors caused during shutdown.
Cherry-picked from the following upstream PRs:
- bitcoin/bitcoin#6719
- bitcoin/bitcoin#6990
- bitcoin/bitcoin#8421
- Second commit only in this PR
- bitcoin/bitcoin#11006
I've cherry-picked the relevant commits, along with a note in each commit referring to the original Bitcoin commit ID (and the Zcash issue numbers where applicable). I've tested each issue with/without these patches applied.
Closes#2214, #2334, and #2554.
When using std::thread in place of boost::thread, letting the threads destruct
results in a std::terminate. According to the docs, the same thing should be
be happening in later boost versions:
http://www.boost.org/doc/libs/1_55_0/doc/html/thread/thread_management.html#thread.thread_management.thread.destructor
I'm unsure why this hasn't blown up already, but explicitly detaching can't
hurt.
Zcash: cherry-picked from commit d3773ca9aeb0d2f12dc0c5a0726778050c8cb455
This fixes#2554 (zcash-cli stop during getblocktemplate long poll
causes 'Assertion `!pthread_mutex_unlock(&m)' failed.')
This continues/fixes #6719.
`event_base_loopbreak` was not doing what I expected it to, at least in
libevent 2.0.21.
What I expected was that it sets a timeout, given that no other pending
events it would exit in N seconds. However, what it does was delay the
event loop exit with 10 seconds, even if nothing is pending.
Solve it in a different way: give the event loop thread time to exit
out of itself, and if it doesn't, send loopbreak.
This speeds up the RPC tests a lot, each exit incurred a 10 second
overhead, with this change there should be no shutdown overhead in the
common case and up to two seconds if the event loop is blocking.
As a bonus this breaks dependency on boost::thread_group, as the HTTP
server minds its own offspring.
Zcash: cherry-picked from commit a264c32e3321ae909ca59cb8ce8bf5d812dbc4e1
This makes sure that the event loop eventually terminates, even if an
event (like an open timeout, or a hanging connection) happens to be
holding it up.
Zcash: cherry-picked from commit ec908d5f7aa9ad7e3487018e06a24cb6449cc58b
Add a WaitExit() call to http's WorkQueue to make it delete the work
queue only when all worker threads stopped.
This fixes a problem that was reproducable by pressing Ctrl-C during
AppInit2:
```
/usr/include/boost/thread/pthread/condition_variable_fwd.hpp:81: boost::condition_variable::~condition_variable(): Assertion `!ret' failed.
/usr/include/boost/thread/pthread/mutex.hpp:108: boost::mutex::~mutex(): Assertion `!posix::pthread_mutex_destroy(&m)' failed.
```
I was assuming that `threadGroup->join_all();` would always have been
called when entering the Shutdown(). However this is not the case in
bitcoind's AppInit2-non-zero-exit case "was left out intentionally
here".
Zcash: cherry-picked from commit de9de2de361ab1355b976f17371d73e36fe3bf56
Fixes#2334 and #2214.
Shutting down the HTTP server currently breaks off all current requests.
This can create a race condition with RPC `stop` command, where the calling
process never receives confirmation.
This change removes the listening sockets on shutdown so that no new
requests can come in, but no longer breaks off requests in progress.
Meant to fix bitcoin/#6717.
Zcash: cherry-picked from commit 5e0c22135600fe36811da3b78216efc61ba765fb
Change the few occurrences of the deprecated `auto_ptr` to c++11 `unique_ptr`.
Silences the deprecation warnings.
Also add a missing `std::` for consistency.
The two timeouts for the server and client, are essentially different:
- In the case of the server it should be a lower value to avoid clients
clogging up connection slots
- In the case of the client it should be a high value to accomedate slow
responses from the server, for example for slow queries or when the
lock is contended
Split the options into `-rpcservertimeout` and `-rpcclienttimeout` with
respective defaults of 30 and 900.
Split StartHTTPServer into InitHTTPServer and StartHTTPServer to give
clients a window to register their handlers without race conditions.
Thanks @ajweiss for figuring this out.
Implement RPCTimerHandler for Qt RPC console, so that `walletpassphrase`
works with GUI and `-server=0`.
Also simplify HTTPEvent-related code by using boost::function directly.
Zcash: QT changes ommitted
- *Replace usage of boost::asio with [libevent2](http://libevent.org/)*.
boost::asio is not part of C++11, so unlike other boost there is no
forwards-compatibility reason to stick with it. Together with #4738 (convert
json_spirit to UniValue), this rids Bitcoin Core of the worst offenders with
regard to compile-time slowness.
- *Replace spit-and-duct-tape http server with evhttp*. Front-end http handling
is handled by libevent, a work queue (with configurable depth and parallelism)
is used to handle application requests.
- *Wrap HTTP request in C++ class*; this makes the application code mostly
HTTP-server-neutral
- *Refactor RPC to move all http-specific code to a separate file*.
Theoreticaly this can allow building without HTTP server but with another RPC
backend, e.g. Qt's debug console (currently not implemented) or future RPC
mechanisms people may want to use.
- *HTTP dispatch mechanism*; services (e.g., RPC, REST) register which URL
paths they want to handle.
By using a proven, high-performance asynchronous networking library (also used
by Tor) and HTTP server, problems such as #5674, #5655, #344 should be avoided.
What works? bitcoind, bitcoin-cli, bitcoin-qt. Unit tests and RPC/REST tests
pass. The aim for now is everything but SSL support.
Configuration options:
- `-rpcthreads`: repurposed as "number of work handler threads". Still
defaults to 4.
- `-rpcworkqueue`: maximum depth of work queue. When this is reached, new
requests will return a 500 Internal Error.
- `-rpctimeout`: inactivity time, in seconds, after which to disconnect a
client.
- `-debug=http`: low-level http activity logging
