-
Notifications
You must be signed in to change notification settings - Fork 7
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
IF: Process votes in a dedicated thread pool #24
Conversation
…bling vote processing
…t easier to test.
…or loop instead.
…at time of C production it will not get a block until A turn. Need to wait at least 7 seconds. Used 10 here to provide a bit of buffer.
@@ -144,7 +144,7 @@ def getSnapshotsCount(nodeId): | |||
while nonProdNode.verifyAlive() and count > 0: | |||
# wait on prodNode 0 since it will continue to advance, since defproducera and defproducerb are its producers | |||
Print("Wait for next block") | |||
assert prodAB.waitForNextBlock(timeout=6), "Production node AB should continue to advance, even after bridge node is killed" | |||
assert prodAB.waitForNextBlock(timeout=10), "Production node AB should continue to advance, even after bridge node is killed" |
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.
6 seconds is not enough time here. There are three producers A,B,C. If this happens to hit on C's turn to produce then it needs to wait at least 7 seconds for a block to be produced. Bumped up to 10 to give a bit of breathing room.
@@ -1226,7 +1226,7 @@ BOOST_AUTO_TEST_CASE(checktime_pause_block_deadline_not_extended_while_loading_t | |||
// WASM load times on my machine was 35ms. | |||
// Since checktime only kicks in after WASM is loaded this needs to be large enough to load the WASM, but should be | |||
// considerably lower than the 150ms max_transaction_time | |||
BOOST_CHECK_MESSAGE( dur < 50'000, "elapsed " << dur << "us" ); | |||
BOOST_CHECK_MESSAGE( dur < 65'000, "elapsed " << dur << "us" ); |
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.
Faild on an asan
run. Took 55ms.
… used to be reported after the call to log_irreversible, they are called before log_irreversible. To avoid confusion by users report what is the known LIB.
…S_ASSERT if configured as a producer with vote processing disabled.
Note:start |
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.
I like it, I think it is simpler and easier to feel confident that it is correct.
Process
vote_message
s in their own dedicated thread pool. The size of the thread pool is configured by a newchain_plugin
config optionvote-threads
. Vote propagation is disabled by default. Vote threads should be enabled on BPs and on canary nodes between BPs. Votes are required to flow from finalizer nodes to all BPs for finality to advance.vote-threads
if not specified is set to 4 on BP nodes.log_irreversible
, but are now called beforelog_irreversible
. To avoid confusion under Savanna, report what the known LIB is instead of what is currently root of the fork db. In legacy mode these will still continue to report the root before the call tolog_irreversible
; therefore under legacy the updated LIB will be reported one block later.vote_message
s are processed first-come-first-serve.Resolves #3
Resolves #4