Use pipeline for world state download #1096
Conversation
…ed before all threads finished processing their last entry.
…sume that earlier entries have completed processing by then.
…rvices take an unusually long time to start.
This reverts commit 3515376.
…entify when profiling and debugging.
…ccess to the same synchronized block anyway. Remove unused parts of WorldDownloadState.
…we mark a task as failed.
…load completes so they can stop waiting.
…peline completes.
| downloadProcessFuture.whenComplete( | ||
| (result, error) -> { | ||
| if (error != null | ||
| && !(ExceptionUtils.rootCause(error) instanceof CancellationException)) { |
There was a problem hiding this comment.
Why do you need to check for a CancellationException here?
There was a problem hiding this comment.
If the pipeline was cancelled it's because the download state cancelled so we don't propagate the cancellation or we'll interfere with the clean up doing. Typically that results in the fast sync being considered as failed when shutting down the client so it deletes its state.
I've added a comment explaining that but may also play with a follow up PR to move starting the pipeline into WorldDownloadState so that it winds up managing the future itself and avoid having the logic split over two classes.
|
|
||
| assertThat(task.isCompleted()).isFalse(); | ||
| assertThat(task.isFailed()).isTrue(); | ||
| verify(downloadState).notifyTaskAvailable(); |
There was a problem hiding this comment.
Should you verify checkCompletion wasn't called?
|
|
||
| @Test | ||
| public void shouldStoreRootNodeDataInDownloadStateInsteadOfPersisting() { | ||
| final Task<NodeDataRequest> rootNode = createTaskWithData(1, 1, 1, 1); |
There was a problem hiding this comment.
You could keep the stateRoot and stateRootHash as instance variables next to blockHeader to make it clearer where this value is coming from.
PR description
Switch world state over to using the pipeline framework to parallelise functions better.