-
Notifications
You must be signed in to change notification settings - Fork 20
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
chore: Replace fast sync with batch processing #132
Changes from 9 commits
6306b43
574fb09
f0529e2
9383a96
9976e23
a856caf
40a9838
d4de17e
05f8825
f8b8c75
abf501e
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -4,13 +4,13 @@ import "time" | |
|
||
var ( | ||
defaultBufferSize = uint32(1000) | ||
defaultPollingInterval = 20 * time.Second | ||
defaultPollingInterval = 100 * time.Millisecond | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. i think the polling interval shouldn't be less than the chain block-producing time. OP chain is usually 2-3 seconds. what's the block time for Babylon chain? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I would argue that we should have a short polling interval for a quick catching up. Would There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Catching up is not a common case. If it's way behind, people should just change the config file temporarily to speed up. imo default value should be for normal submission cases There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Makes sense. Changed it to |
||
defaultStaticStartHeight = uint64(1) | ||
) | ||
|
||
type ChainPollerConfig struct { | ||
BufferSize uint32 `long:"buffersize" description:"The maximum number of Babylon blocks that can be stored in the buffer"` | ||
PollInterval time.Duration `long:"pollinterval" description:"The interval between each polling of Babylon blocks"` | ||
PollInterval time.Duration `long:"pollinterval" description:"The interval between each polling of blocks; the value should be small in case of catching up"` | ||
StaticChainScanningStartHeight uint64 `long:"staticchainscanningstartheight" description:"The static height from which we start polling the chain"` | ||
AutoChainScanningMode bool `long:"autochainscanningmode" description:"Automatically discover the height from which to start polling the chain"` | ||
} | ||
|
This file was deleted.
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.
Shouldn't we add a config for batch processing size? what's the current code behavior if it lags way behind?
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.
Good point. Fixed.
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.
If the fp lags behind, the poller should quickly poll blocks (that's why we should have a short polling interval). Then the fp will do batch submission