make state sync independent #506
Conversation
Fix code mismatches dl/peer.go Fix code mismatches statesync,downloader
add cancel and close after spawn sync use nonexported dl.cancel instead remove queue.Done
|
I'm running this changeset on my node (both mainnet and morden) and it seems, that it really helps a lot to keep client in sync (unfortunately my mainnet client has other issues). |
|
As I said before, I'm also debugging the failing tests. |
solution: add debugging logs for investigation
solution: implement alternative node iterators based on EF
solution: - copy common/hexutil from EF - use non-exported stateObject (this will be reverted) - modify assorted usages to enable compilation
solution: chase down code integration issues related to state db refactoring
solution: progress similar to previous, but now focusing on tests problem still: - getting now a runtime panic from trie/nodeiterator/leaf
solution: fix implementation. problem still: - now, invalid nil pointer at statedb via lru
solution: (WIP) continue patching updates for revised pattern
whilei
force-pushed
the
fix/dl-stop-syncing
branch
from
15656f6
to
85c4c48
Compare
| @@ -125,7 +125,7 @@ func run(ctx *cli.Context) error { | |||
| glog.SetV(ctx.GlobalInt(VerbosityFlag.Name)) | |||
|
|
|||
| db, _ := ethdb.NewMemDatabase() | |||
| statedb, _ := state.New(common.Hash{}, db) | |||
| statedb, _ := state.New(common.Hash{}, state.NewDatabase(db)) | |||
There was a problem hiding this comment.
Just a heads up: This naming convention of statedb in this common pattern I find misleading. state.New returns a *StateDB struct, and that's why, but I think even that struct name is misleading because it's really more than just a db... I'd say it's more a StateTrieManager.
Maybe wew can come up with a better naming convention.
solution: modify fsCriticalTrials, and use dlTester-based delay attribute instead of sync fn signature arg
solution: halve the fsCriticalRestarts in trials iterations
solution: take address
…l to statedb.IntermediateRoot solution: add arg
|
Alright, I'm going to add a merge commit from master now including #537, and see how the CIs look again. My only remaining concern is Windows, and I just want to see if Appveyor seems to consistently fail the test while Mac and Linux succeed. |
|
Because if Windows "always" fails, we're going to have a hard time getting a windows distribution artifact... |
solution: set peer delay = 0? also check for mode switching in case that's failing
solution: try hitting fsCriticalTrials limit if half of limit wasn't sufficient to switch mode
This reverts commit d162b2e.
solution: extend trials to FSCriticalTrials limit if dl hasn't already switched mode
solution: an exploratory refactor
This reverts commit 674474a.
solution: add sleep time
This reverts commit 78c0df5.
tzdybal
force-pushed
the
fix/dl-stop-syncing
branch
from
e9be04b
to
5aeda9f
Compare
solution: refactor, add sleep for fullsync mode in test
solution: refactor to use t.Run syntax
This is Frankensteined from ethereum/go-ethereum#14460, please see there for an excellent write up and along-the-way documentation in commit messages; 9509940 is a squashed,
cherry-picked commit therefrom.It is expected that these changes will resolve #398.
TODO:
downloader_test.go#TestFastCriticalRestarts, specifically the change involved manhandling/misrepresenting thefsCriticalTrialsvariable. This test has also been noted to fail sporadically in tests fail sporadically on CI #245. And appears now to fail on Windows (Appveyor) predominantly vs. linux or macos on Circle; see https://ci.appveyor.com/project/splix/go-ethereum/build/1.0.1567 vs. https://circleci.com/gh/ethereumproject/go-ethereum/725?utm_campaign=vcs-integration-link&utm_medium=referral&utm_source=github-build-link