-
Notifications
You must be signed in to change notification settings - Fork 880
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 <gabriel.trintinalia@consensys.net>
Signed-off-by: Gabriel Trintinalia <gabriel.trintinalia@consensys.net>
Signed-off-by: Gabriel Trintinalia <gabriel.trintinalia@consensys.net>
Signed-off-by: Gabriel Trintinalia <gabriel.trintinalia@consensys.net>
Signed-off-by: Gabriel Trintinalia <gabriel.trintinalia@consensys.net>
Signed-off-by: Gabriel Trintinalia <gabriel.trintinalia@consensys.net>
Signed-off-by: Gabriel Trintinalia <gabriel.trintinalia@consensys.net>
Signed-off-by: Gabriel Trintinalia <gabriel.trintinalia@consensys.net>
…-Trintinalia/besu into 3955-besu-stop-importing
Signed-off-by: Gabriel Trintinalia <gabriel.trintinalia@consensys.net>
…ancestors of Block Signed-off-by: Gabriel Trintinalia <gabriel.trintinalia@consensys.net>
Signed-off-by: Gabriel Trintinalia <gabriel.trintinalia@consensys.net>
…ing pending block to the list Signed-off-by: Gabriel Trintinalia <gabriel.trintinalia@consensys.net>
Signed-off-by: Gabriel Trintinalia <gabriel.trintinalia@consensys.net>
Signed-off-by: Gabriel Trintinalia <gabriel.trintinalia@consensys.net>
Signed-off-by: Gabriel Trintinalia <gabriel.trintinalia@consensys.net>
Signed-off-by: Gabriel Trintinalia <gabriel.trintinalia@consensys.net>
Signed-off-by: Fabio Di Fabio <fabio.difabio@consensys.net>
Signed-off-by: Fabio Di Fabio <fabio.difabio@consensys.net>
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 <fabio.difabio@consensys.net>
Signed-off-by: Fabio Di Fabio <fabio.difabio@consensys.net>
Signed-off-by: Fabio Di Fabio <fabio.difabio@consensys.net>
Signed-off-by: Fabio Di Fabio <fabio.difabio@consensys.net>
Signed-off-by: Fabio Di Fabio <fabio.difabio@consensys.net>
…d in RetryingGetBlockFromPeers Signed-off-by: Fabio Di Fabio <fabio.difabio@consensys.net>
Signed-off-by: Fabio Di Fabio <fabio.difabio@consensys.net>
Signed-off-by: Fabio Di Fabio <fabio.difabio@consensys.net>
Signed-off-by: Fabio Di Fabio <fabio.difabio@consensys.net>
# 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 <fabio.difabio@consensys.net>
@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 <fabio.difabio@consensys.net>
…yperledger#4271) Signed-off-by: Fabio Di Fabio <fabio.difabio@consensys.net>
…yperledger#4271) Signed-off-by: Fabio Di Fabio <fabio.difabio@consensys.net> Signed-off-by: garyschulte <garyschulte@gmail.com>
…yperledger#4271) Signed-off-by: Fabio Di Fabio <fabio.difabio@consensys.net>
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