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

Limit outgoing block range request size #1061

Merged
merged 11 commits into from
Dec 16, 2019

Conversation

cemozerr
Copy link
Contributor

PR Description

Limit outgoing block range request size

Copy link
Contributor

@ajsutton ajsutton left a comment

Choose a reason for hiding this comment

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

Looks like the tests need updating to handle these changes.

sync/src/main/java/tech/pegasys/artemis/sync/PeerSync.java Outdated Show resolved Hide resolved
sync/src/main/java/tech/pegasys/artemis/sync/PeerSync.java Outdated Show resolved Hide resolved
private final ChainStorageClient storageClient;
private final BlockImporter blockImporter;

private UnsignedLong latestRequestedSlot;
Copy link
Contributor

Choose a reason for hiding this comment

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

This needs to be volatile as it's used both when the initial call to sync comes in and in response to blocks being received from the peer which may happen on different threads.

private final BlockImporter blockImporter;

private UnsignedLong latestRequestedSlot;
private final CompletableFuture<PeerSyncResult> finalResult = new CompletableFuture<>();
Copy link
Contributor

Choose a reason for hiding this comment

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

It's a bit of an anti-pattern to have a "finalResult" type future like this. Ideally we'd just chain CompletableFuture calls all the way down and just return that without having to "copy" the result to this future. The benefit of using full chaining is you guarantee never to "lose" an exception. If an exception throws anywhere in the process it will automatically be passed back up the chain. Whereas when copying the result if an exception is thrown in the whenComplete function within executeSync it will be silently ignored because the return value from requestSyncBlocks is never used.

There are times when copying to a result future is required but in this case I think we can manage it. See master...ajsutton:chain-futures We probably should talk about how we want to approach CompletableFuture handling - it can easily get unwieldy but since we're just starting to use them if we think about it a bit we can probably define some good patterns and utility methods to support them so we get it right.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Agreed. We should talk about how we want to approach CompletableFutures.


enum PeerSyncResult {
SUCCESSFUL_SYNC,
FAULTY_ADVERTISEMENT
Copy link
Contributor

Choose a reason for hiding this comment

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

We only ever use SUCCESSFUL_SYNC as the result - FAULTY_ADVERTISEMENT is returned via an exception.

Copy link
Contributor

@ajsutton ajsutton left a comment

Choose a reason for hiding this comment

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

LGTM.

@cemozerr cemozerr merged commit 9f9b1e3 into Consensys:master Dec 16, 2019
@cemozerr cemozerr deleted the limitOutgoingBlockRangeRequestSize branch December 16, 2019 23:24
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.

2 participants