-
Notifications
You must be signed in to change notification settings - Fork 26
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
algod importer: Update sync on WaitForBlock error. #122
Merged
Merged
Changes from all commits
Commits
Show all changes
11 commits
Select commit
Hold shift + click to select a range
4284e64
Bugfix
winder 7598a48
WIP
winder 44b7735
Fix tests.
winder 77e247f
Update test name.
winder 3cbacad
Linter fix
winder 610a7b9
Add helpful comment to test.
winder 67a58eb
Be slightly more aggressive with the SyncError.
winder 2f5dd92
Fix tests, add another test.
winder 72c5dd4
Fix the other test...
winder fc9a9b5
PR feedback.
winder 042ec0b
Help distinguishing unknown errors.
winder File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
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
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
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
Oops, something went wrong.
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.
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.
Nit:
A more conservative timeout would be 45 seconds. I agree that we want to endow conduit with a greater amount of determinism regarding the outcome of each call to the
waitForBlock
endpoint. So it's a good idea to make the call to the endpoint timeout on it's own terms rather than the endpoint's as is being done in the PR. On the other hand, we might still want the ability to keep 10 threads of the algod importer running concurrently after we've all caught up, and a 45 sec timeout would allow for that. If we narrow the timeout to 5 secs, we essentially only allow one or two algod importer threads to run at a time (probably only one due to round time variability).On the other hand, we can change the value as aggressively as in the PR, and if the need arises in the future to raise it back to 45 secs we can do it.
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.
The low timeout was intended for responsiveness, basically when the node is stalled the timeout needs to elapse before the first recovery attempt. If there's a timeout I'm expecting the pipeline to retry the call.
The default retry count is 5, now I'm wondering if it should be unlimited.
The old Indexer had a package called fetcher, I wonder if we should bring that back to manage more optimal round caching: https://github.com/algorand/indexer/blob/master/fetcher/fetcher.go#L1
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.
A worthwhile thought for a future PR or even the pipelining effort. (suggest keeping this thread unresolved for future reference)
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.
I'll change the default retry timeout to 0 in a followup PR, it's probably a good default anyway since people have expressed appreciation for Indexer working that way.
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.
#125