Skip to content
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

Use retry switching peer for world state download tasks #5508

Closed
wants to merge 34 commits into from

Conversation

fab-10
Copy link
Contributor

@fab-10 fab-10 commented May 29, 2023

PR description

Built on top of #5509, so please check it first. Link to only see diff again #5509

With this PR all the world state download tasks used by snap sync are updated to use the retry switching peer strategy, to reduce the chance that we keep sending requests to the same bad peer.

relates to #5415 and #5271

@github-actions
Copy link

github-actions bot commented May 29, 2023

  • I thought about documentation and added the doc-change-required label to this PR if updates are required.
  • I have considered running ./gradlew acceptanceTestNonMainnet locally if my PR affects non-mainnet modules.
  • I thought about the changelog and included a changelog update if required.
  • If my PR includes database changes (e.g. KeyValueSegmentIdentifier) I have thought about compatibility and performed forwards and backwards compatibility tests

super(
ethContext,
metricsSystem,
data -> data.proofs().isEmpty() && data.slots().isEmpty(),
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A bad peer will be a peer with this kind of result
I’m not sure you are checking if the response is like that in order to switch to another peer

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

check this other PR #5509, that checks and records the empty response in the AbstractRetryingPeerTask

…e-retry-switching-peer

# Conflicts:
#	ethereum/eth/src/main/java/org/hyperledger/besu/ethereum/eth/manager/snap/RetryingGetAccountRangeFromPeerTask.java
#	ethereum/eth/src/main/java/org/hyperledger/besu/ethereum/eth/manager/snap/RetryingGetBytecodeFromPeerTask.java
#	ethereum/eth/src/main/java/org/hyperledger/besu/ethereum/eth/manager/snap/RetryingGetStorageRangeFromPeerTask.java
#	ethereum/eth/src/main/java/org/hyperledger/besu/ethereum/eth/manager/snap/RetryingGetTrieNodeFromPeerTask.java
#	ethereum/eth/src/main/java/org/hyperledger/besu/ethereum/eth/manager/task/RetryingGetNodeDataFromPeerTask.java
Signed-off-by: Fabio Di Fabio <[email protected]>
@fab-10 fab-10 marked this pull request as ready for review May 30, 2023 14:41
@fab-10 fab-10 requested a review from matkt May 30, 2023 14:42
@fab-10 fab-10 self-assigned this May 30, 2023
Copy link
Contributor

@siladu siladu left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Diff looks pretty straightforward. Couple of small comments. Don't want to approve while the parent PR is in flight

@@ -155,7 +166,8 @@ public void completesWhenPeersAreTemporarilyUnavailable()
final T requestedData = generateDataToBeRequested();

// Execute task and wait for response
final EthTask<T> task = createTask(requestedData);
// +2 is required for switching peers tasks where the max retries = number of peers
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

useful comment 👍

@@ -320,7 +320,9 @@ public Stream<EthPeer> streamAvailablePeers() {
}

public Stream<EthPeer> streamBestPeers() {
return streamAvailablePeers().sorted(getBestChainComparator().reversed());
return streamAvailablePeers()
.filter(EthPeer::isFullyValidated)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why is this required?

@matkt
Copy link
Contributor

matkt commented Jun 1, 2023

Just a question. A peer that is useless for the worldstate part may not be for the blockchain part. Is there not a risk of losing valid nodes for a certain type of data by marking useless when it could still help us. For example Besu and Nethermind which do not provide Snapsync data but remain valid for the blockchain. Should not have a more complex notion of useless ?

@fab-10 fab-10 marked this pull request as draft June 5, 2023 10:45
@matkt
Copy link
Contributor

matkt commented Jun 22, 2023

testing currently the PR with my snapsync boost feature

@fab-10 fab-10 removed their assignment Mar 27, 2024
@macfarla
Copy link
Contributor

Blocked by #6609 - without that we would disconnect peers, because we are trying peers that do not serve snap data.

@jframe
Copy link
Contributor

jframe commented Jul 9, 2024

@fab-10 Closing this, reopen if think we still need it

@jframe jframe closed this Jul 9, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants