-
Notifications
You must be signed in to change notification settings - Fork 795
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
Update confirmation height in another thread #1877
Update confirmation height in another thread #1877
Conversation
6195e41
to
dda6ca3
Compare
…ng to see what hash is currently ungoing confirmation height processing
…t the tested accounts auto receiving the blocks
…he RPC request to reduce timing issues with ci.
de4a441
to
c2b2068
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
@wezrule Can you help review the stats RPC documentation and help suggest updates? https://docs.nano.org/commands/rpc-protocol/#stats and https://docs.nano.org/running-a-node/troubleshooting/#statistics-from-rpc. Looks like we may want to combine and possibly expand some pieces, not sure. The other RPC and CLI command in this ticket look good in the docs. Another related stats ticket: #1955 |
@zhatt it was quite out of date, have added the missing stats. |
Thanks! |
Currently the confirmation height is updated on io threads, and if it touches a long chain it can take a very long time (30 minutes) because it can update pretty much the whole ledger. A different approach is now taken. When a block being confirmed, we go down to the lowest block in the chain which has not been confirmed and store each receive block along the way. We now start at the lowest (before it would have been the highest) receive and iterate to the source accounts until we get to a chain where there are no more unconfirmed receives, storing this in a collection of pending writes , working our way from the bottom upwards.
API changes:
RPC stats -> counters.
confirmed_block_count
shows the number of blocks confirmed during node start-upRPC stats -> objects.
confirmation_height_processor
->receive_source_pairs
. The current number of receive-source pairs that still await iterative confirmation for the current block being confirmed.pending_confirmation_height
->pending
- The number of top level block hashes in the queue awaiting confirmationRPC
{"action":"confirmation_height_currently_processing"}
this will return the hash if any which is currently being processed. To be marked as unstable/debug.CLI:
--debug_cemented_block_count
iterates over all account chains and sums up the confirmation heights (can take a little bit). For the first time the node is launched this will be 1 more than that in stats -> counters due to the implicitly confirmed genesis block.