-
Notifications
You must be signed in to change notification settings - Fork 411
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Async mempool scanning #970
base: master
Are you sure you want to change the base?
Conversation
Many thanks! |
da11fc8
to
0162c5f
Compare
Requested changes force pushed, amending the existing commits. @romanz you can view the diffs here. If you feel comfortable with that, i'll submit 9b5f925 and ed42680 as a new PR. |
PR open here, this PR is now dependent on that one |
Please rebase over |
0162c5f
to
cd4c279
Compare
Rebase complete 👍 |
Please rebase over latest |
Could you please take a look at the failure?
IIUC, it seems that the broadcasted transaction is not being reported back to Electrum client. |
You can modify diff --git a/tests/run.sh b/tests/run.sh
index e19b4d2..b19d8cd 100755
--- a/tests/run.sh
+++ b/tests/run.sh
@@ -13,6 +13,7 @@ cleanup() {
kill $j
wait $j
done
+ cat data/electrs/regtest-debug.log
}
trap cleanup SIGINT SIGTERM EXIT
@@ -68,6 +69,8 @@ NEW_ADDR=`$EL getunusedaddress`
echo " * payto & broadcast"
TXID=$($EL broadcast $($EL payto $NEW_ADDR 123 --fee 0.001 --password=''))
+sleep 20
+
echo " * get_tx_status"
test "`$EL get_tx_status $TXID | jq -c .`" == '{"confirmations":0}' |
cd4c279
to
221a10a
Compare
Rebased ✅ I'm now looking into the mempool missing TX error. My guess is that async mempool scanning results in a delayed reaction where Prior to this PR, the synchronous nature of mempool scanning meant that after broadcasting a transaction, the next iteration of the main thread's event loop triggered a mempool scan, and further client requests (like the subsequent TX lookup) weren't processed until the mempool scan was complete, so the request always got the most up-to-date view of the mempool possible after broadcasting. I see two options to address this:
I think option 2 is the more appropriate choice. I don't see any obvious associated negatives. The mempool sync thread should remove the entry later if the broadcasted TX we add manually is evicted for some reason. Still waiting for the dockerfile to build for the moment. i'll return tomorrow with an update once I've verified my suspicions |
@romanz sorry for the delay. My suspicions were correct, and I applied a fix which automatically appends the newly broadcasted TX to the mempool immediately upon broadcast. |
5eb41f0
to
c56cca4
Compare
@conduition Could you please review #979 which should also help when syncing large mempools? |
The mempool scanning procedure can now be launched in a separate thread, while mempool updates are applied synchronously in the main thread.
c56cca4
to
a07b70d
Compare
Putting this briefly into Draft state; i found I was getting spurious logs after a07b70d.
will fix |
a07b70d
to
2d50ebe
Compare
OK should be fixed now |
Hey @romanz, just wanted to check in and see if I should take the time to rebase this or? |
Fixes #968. Mempool scanning is now done asynchronously in a separate thread called the
mempool_sync
thread.Method
My approach was to split the
Mempool::sync
method into two parts: (1) fetching the updated mempool transactions [slow, read-only] and (2) applying those transactions [fast, write].HashSet<Txid>
to themempool_sync
thread. This set represents the current set of TXIDs in the mempool which we already know about.mempool_sync
thread proceeds to scan the mempool from the remote node. While the scan is ongoing (could take a long time) the main thread can still process block updates, script notifications, and electrum client requests.mempool_sync
thread blocks until it can send aMempoolSyncUpdate
to the main thread.Mempool
, viaRpc::mempool_apply
. This adds new transactions, removes outdated ones, and updates the fee histogram.Advantages
Scanning is asynchronous and read-only, while writing the update to the mempool's in-memory state is synchronous WRT the main-thread. This way, we don't introduce any mutexes because we don't need concurrent read/writes of
Mempool
. Electrum client requests are always processed with a consistent view of the mempool, even if a scan is ongoing and could finish at any time.Histogram Perf
While i was in there, I improved the performance of applying mempool updates, by avoiding needless recomputation of the
FeeHistogram
from scratch every time. Instead we dynamically update fee histogram bins according to which transactions have been added or removed. I added unit tests to demonstrate the logic is sound. If preferable, I can separate theFeeHistogram
changes and package it into another PR (although it will probably conflict with this one).