This repository has been archived by the owner on Sep 26, 2019. It is now read-only.
Queue pending requests when all peers are busy #1331
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
… include the time queueing for an available peer.
…ing with pending peer requests. Send all peer requests through EthPeers, even if a specific peer has been requested.
…ps (PegaSysEng#1318) * Allow private contract invocations in multiple privacy groups
Store the header for the current chain head and total difficulty to avoid RocksDB lookups when requesting those common values. Also uses that cache to avoid a database lookup when checking if a block has already been imported if the block's parent is the current chain head.
* combine bootnodes and staticNodes and pass the combined collection when building permissioning config; renamed error code that specifically called out bootnodes
… the same number of outstanding requests. Ensures we cycle round all our peers to avoid sybil attacks.
mbaxter
approved these changes
May 2, 2019
| * @param onError handler for when there is no peer with sufficient height or the request fails to | ||
| * send | ||
| */ | ||
| public void thenEither( |
There was a problem hiding this comment.
(optional) From javascript, I would expect this to be called then.
| } | ||
|
|
||
| private void useRequestSlot(final EthPeer peer) throws PeerNotConnected { | ||
| peer.getNodeData(emptyList()); |
There was a problem hiding this comment.
Seems like getNodeData() should throw an exception here. For now, it's probably worth at least sending a non-empty list to this method in order to future-proof these tests.
and removed changes made in application JS as the new version of material theme fixes the issue with hotjar form
notlesh
pushed a commit
to notlesh/pantheon
that referenced
this pull request
May 4, 2019
Provides better control over the maximum number of concurrent requests to a peer. Gives a fairer allocation of peers to requests being made. Avoids a task failing because all peers are busy which then introduces a delay before the request is retried.
notlesh
pushed a commit
to notlesh/pantheon
that referenced
this pull request
May 14, 2019
Provides better control over the maximum number of concurrent requests to a peer. Gives a fairer allocation of peers to requests being made. Avoids a task failing because all peers are busy which then introduces a delay before the request is retried.
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
PR description
Modify how idle peers are found so that instead of picking one and then separately sending the request, that's done in a single atomic operation. This ensures that two threads don't select the same peer and both send requests to it, potentially breaching the outstanding request limit.
Additionally, if all suitable peers are busy queue the request and perform it when a peer is available instead of throwing NoAvailablePeersException. This avoids aborting pipelines when there is a lot of contention for peers and provides a fairer sharing of peers between the various threads that need to request data.