And use it to fix a race condition in mempool_persist.py: https://travis-ci.org/Empact/bitcoin/jobs/487577243
Since e.g. getrawmempool returns errors based on this status, this enables users to test it for readiness.
Fixes #12863
And use it to fix a race condition in mempool_persist.py: https://travis-ci.org/Empact/bitcoin/jobs/487577243
Since e.g. getrawmempool returns errors based on this status, this enables users to test it for readiness.
Fixes #12863
The test failure, for reference:
0stdout:
12019-02-01T20:25:18.578000Z TestFramework (INFO): Initializing test directory /tmp/test_runner_₿_🏃_20190201_201908/mempool_persist_74
22019-02-01T20:25:27.680000Z TestFramework (ERROR): Assertion failed
3Traceback (most recent call last):
4 File "/home/travis/build/Empact/bitcoin/build/bitcoin-x86_64-unknown-linux-gnu/test/functional/test_framework/util.py", line 113, in try_rpc
5 fun(*args, **kwds)
6 File "/home/travis/build/Empact/bitcoin/build/bitcoin-x86_64-unknown-linux-gnu/test/functional/test_framework/coverage.py", line 47, in __call__
7 return_val = self.auth_service_proxy_instance.__call__(*args, **kwargs)
8 File "/home/travis/build/Empact/bitcoin/build/bitcoin-x86_64-unknown-linux-gnu/test/functional/test_framework/authproxy.py", line 136, in __call__
9 raise JSONRPCException(response['error'])
10test_framework.authproxy.JSONRPCException: The mempool was not loaded yet (-1)
11During handling of the above exception, another exception occurred:
12Traceback (most recent call last):
13 File "/home/travis/build/Empact/bitcoin/build/bitcoin-x86_64-unknown-linux-gnu/test/functional/test_framework/test_framework.py", line 174, in main
14 self.run_test()
15 File "/home/travis/build/Empact/bitcoin/build/bitcoin-x86_64-unknown-linux-gnu/test/functional/mempool_persist.py", line 130, in run_test
16 assert_raises_rpc_error(-1, "Unable to dump mempool to disk", self.nodes[1].savemempool)
17 File "/home/travis/build/Empact/bitcoin/build/bitcoin-x86_64-unknown-linux-gnu/test/functional/test_framework/util.py", line 105, in assert_raises_rpc_error
18 assert try_rpc(code, message, fun, *args, **kwds), "No exception raised"
19 File "/home/travis/build/Empact/bitcoin/build/bitcoin-x86_64-unknown-linux-gnu/test/functional/test_framework/util.py", line 119, in try_rpc
20 raise AssertionError("Expected substring not found:" + e.error['message'])
21AssertionError: Expected substring not found:The mempool was not loaded yet
222019-02-01T20:25:27.682000Z TestFramework (INFO): Stopping nodes
232019-02-01T20:25:27.985000Z TestFramework (WARNING): Not cleaning up dir /tmp/test_runner_₿_🏃_20190201_201908/mempool_persist_74
242019-02-01T20:25:27.985000Z TestFramework (ERROR): Test failed. Test logging available at /tmp/test_runner_₿_🏃_20190201_201908/mempool_persist_74/test_framework.log
252019-02-01T20:25:27.985000Z TestFramework (ERROR): Hint: Call /home/travis/build/Empact/bitcoin/build/bitcoin-x86_64-unknown-linux-gnu/test/functional/combine_logs.py '/tmp/test_runner_₿_🏃_20190201_201908/mempool_persist_74' to consolidate all logs
26stderr:
1508@@ -1508,6 +1509,7 @@ static UniValue getmempoolinfo(const JSONRPCRequest& request)
1509 {},
1510 RPCResult{
1511 "{\n"
1512+ " \"loaded\": true|false (boolean) True if the mempool has been loaded/initialized.\n"
-persistmempool
is off, g_is_mempool_loaded
is set at the end of ThreadImport
, after block import. Ideas on how to articulate that? Perhaps we could set it earlier in that case -persistmempool
?
/initialized
?
True if the mempool has been loaded from disk (if persistent)
True if the mempool has been loaded from disk (if persistent), or need not be
is much less clear than the more simple True if the mempool is fully loaded.
The first raises more questions than it answers (“What is persistent? When need it not be?”)
s/persist/-persistmempool/g
?
Concept ACK. Could add a release note with the new key. This introduces a weird case, which is loaded
can change from true
to false
. Maybe
https://github.com/bitcoin/bitcoin/blob/b3a715301a0fd972fb2f3bd36e2680b3cdbbab26/src/init.cpp#L707
should change to
0 g_is_mempool_loaded |= !ShutdownRequested();
The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.
Reviewers, this pull request conflicts with the following ones:
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.
/rest/mempool/info.json
is also affected.
Revised and cleaned up:
/rest/mempool/info.json
to include the attribute (thanks @promag)g_is_mempool_loaded
strictly between the persistmempool
and non-persist case - note it’s only relevant on shutdown if persistmempool
is set: https://github.com/bitcoin/bitcoin/blob/8f470ecc534d49cb5f7045ea9564481acd3e2b4b/src/init.cpp#L238-L240100@@ -100,14 +101,16 @@ def run_test(self):
101 self.log.debug("Stop-start node0 with -persistmempool=0. Verify that it doesn't load its mempool.dat file.")
102 self.stop_nodes()
103 self.start_node(0, extra_args=["-persistmempool=0"])
104+ assert self.nodes[0].getmempoolinfo()["loaded"]
105 # Give bitcoind a second to reload the mempool
106 time.sleep(1)
ACK the first and third commits (rpc: Expose g_is_mempool_loaded via getmempoolinfo and /rest/mempool/info.json and Move g_is_mempool_loaded into CTxMemPool::m_is_loaded). I like the tidy up in Move g_is_mempool_loaded into CTxMemPool::m_is_loaded to remove the g_is_mempool_loaded
global.
I don’t see the need for the second commit (rpc: Set g_is_mempool_loaded early if the mempool is not persisted). Having two places where m_is_loaded_
gets set seems to add complexity for no good reason. I don’t think any users will see any behaviour difference before and after that commit.
And use it to fix a race condition in mempool_persist.py:
https://travis-ci.org/Empact/bitcoin/jobs/487577243
Since e.g. getrawmempool returns errors based on this status, this
enables users to test it for readiness.
So the loaded state is explicitly mempool-specific.
utACK effe81f750
Signature:
0-----BEGIN PGP SIGNED MESSAGE-----
1Hash: SHA512
2
3utACK effe81f750
4-----BEGIN PGP SIGNATURE-----
5
6iQGzBAEBCgAdFiEE+rVPoUahrI9sLGYTzit1aX5ppUgFAlwqrYAACgkQzit1aX5p
7pUgQDgv/Vu+DeQYZkt0Au46dAPXOWF5uIfLHOGhOHbKB+YZ6zFNIrmw6VF5XrYDl
8IJqLlqX2WtDQd8gYcQ9dDvVSBktaJrk6Qm9laEX8qITMavz5VHK8rHfqmJ9nrqC8
9DNgWMlwhoQsJqflqXeaUKnkXv9eoMLvuHVn+F3kDkr9Wu/AjRjLxu1zaE9qnr0sl
10lO8Z+mdVig4NDWbCHwZHyvP+eM8skn5WeEXTSi6Vl1yqgEP9T/9TEFQtlQ1ikTjn
11t+ACMSxzfest155gsZt0vxn5ABlfw1phw3b/x6DEFIFNzs0cBYVRxu8kPhTarqYL
12gMcrAvVlfs9knGDUaU4XaZbfor/cQRAduFCKqowSxob4jwb2FcWX9jDCxuyCBge7
13kPS1qFNI0eBRw0OLSKKq3A5wH8Oyvx5XzagoRkFcKCz2hF1KqFfLKT+EyBViBWbR
14lW6qMTO+A26VJsslpzaTpfnQrTU3mfyUxJB3+IPVQ0Mcibt2jBdfYJCq0/W+DIGe
15RtTjJIFt
16=u6Rr
17-----END PGP SIGNATURE-----
Timestamp of file with hash fcca790e597327e6dbf958e78e5e5c02c0911ef653160c591bf56423b214127d -