-
Notifications
You must be signed in to change notification settings - Fork 897
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
Retry mechanism when getting a broadcasted block fail on all peers #4271
Conversation
Signed-off-by: Gabriel Trintinalia <[email protected]>
Signed-off-by: Gabriel Trintinalia <[email protected]>
Signed-off-by: Gabriel Trintinalia <[email protected]>
Signed-off-by: Gabriel Trintinalia <[email protected]>
Signed-off-by: Gabriel Trintinalia <[email protected]>
Signed-off-by: Gabriel Trintinalia <[email protected]>
Signed-off-by: Gabriel Trintinalia <[email protected]>
Signed-off-by: Gabriel Trintinalia <[email protected]>
Signed-off-by: Gabriel Trintinalia <[email protected]>
…-Trintinalia/besu into 3955-besu-stop-importing
Signed-off-by: Gabriel Trintinalia <[email protected]>
…ancestors of Block Signed-off-by: Gabriel Trintinalia <[email protected]>
Signed-off-by: Gabriel Trintinalia <[email protected]>
…ing pending block to the list Signed-off-by: Gabriel Trintinalia <[email protected]>
Signed-off-by: Gabriel Trintinalia <[email protected]>
Signed-off-by: Gabriel Trintinalia <[email protected]>
Signed-off-by: Gabriel Trintinalia <[email protected]>
Signed-off-by: Gabriel Trintinalia <[email protected]>
Signed-off-by: Fabio Di Fabio <[email protected]>
Signed-off-by: Fabio Di Fabio <[email protected]>
RetryingGetBlockFromPeersTask had a problem that prevented to complete when all the peers were tried without success, and that also had the consequence to not removing the failed requested block for the internal caches in BlockPropagationManager, that could cause a stall since that block will to be tried to be retrieved again. Signed-off-by: Fabio Di Fabio <[email protected]>
Signed-off-by: Fabio Di Fabio <[email protected]>
Signed-off-by: Fabio Di Fabio <[email protected]>
Signed-off-by: Fabio Di Fabio <[email protected]>
Signed-off-by: Fabio Di Fabio <[email protected]>
…d in RetryingGetBlockFromPeers Signed-off-by: Fabio Di Fabio <[email protected]>
Signed-off-by: Fabio Di Fabio <[email protected]>
Signed-off-by: Fabio Di Fabio <[email protected]>
Signed-off-by: Fabio Di Fabio <[email protected]>
Signed-off-by: Fabio Di Fabio <[email protected]>
# Conflicts: # CHANGELOG.md # ethereum/eth/src/test/java/org/hyperledger/besu/ethereum/eth/sync/AbstractBlockPropagationManagerTest.java
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.
one minor non-blocking suggestion, looks good though.
if (!config.getBlockPropagationRange().contains(distanceFromChainHead)) { | ||
debugLambda( | ||
LOG, | ||
"Not retrying to get block {} since we are too far from local chain head {}", |
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.
Is this a good place to suggest the user to start over with a checkpoint sync? If we got here during a backwards sync, that might be the only way to recover.
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.
Not sure I got this, backward sync does not run along with BlockPropagationManager
…ck data structures Signed-off-by: Fabio Di Fabio <[email protected]>
@jflo added a timeout and did some refactoring in the last commit, do you mind to review again? |
…yperledger#4271) Signed-off-by: Fabio Di Fabio <[email protected]>
…yperledger#4271) Signed-off-by: Fabio Di Fabio <[email protected]>
…yperledger#4271) Signed-off-by: Fabio Di Fabio <[email protected]> Signed-off-by: garyschulte <[email protected]>
…yperledger#4271) Signed-off-by: Fabio Di Fabio <[email protected]>
PR description
Currently even if we use the RetryingGetBlockFromPeers, that tries to download the block, checking every peer in turn, if all peers fail, the retrieval is not repeated, unless the block is announced again.
This PR improve the block propagation manager, to repeat the download of a block, until some conditions apply: it is still not imported and the distance from the local head is within configured range.
Fixed Issue(s)
relates to #3955
Documentation
doc-change-required
label to this PR ifupdates are required.
Changelog