Skip to content
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

Enabling JournalPruneDataSource #478

Merged
merged 10 commits into from Jun 1, 2018
Merged

Conversation

AlexandraRoatis
Copy link
Contributor

Description

Please include a brief summary of the change that this pull request proposes. Include any relevant motivation and context. List any dependencies required for this change.

  • minor cleanup in BlockchainDataRecoveryTest.java
  • re-enabling the use of JournalPruneDataSource.java for Trie pruning
  • configuration setting for the number of recent blocks to be maintained in the database (with a minimum value set to 128)
  • utils for exploring the state trie
  • functionality for rebuilding the genesis block when recovery is triggered by a missing state at kernel startup
  • unit tests for the JournalPruneDataSource.java data storage and retrieval operations

Fixes Issue #298.

Type of change

Insert x into the following checkboxes to confirm (eg. [x]):

  • Bug fix.
  • New feature.
  • Breaking change (a fix or feature that causes existing functionality to not work as expected).
  • Requires documentation update.

Testing

Please describe the tests you used to validate this pull request. Provide any relevant details for test configurations as well as any instructions to reproduce these results.

In addition to the unit tests above:

  • the kernel was run with different settings of pruneBlockCount (10, 100, 1000, 10000) for over 24 hours, only the version keeping only 10 blocks resulted in issues, which are now avoided due to the minimum value setting
  • ran the kernel with negative and zero pruneBlockCount and can confirm pruning disabled
  • unit tests show that values are not cached when the pruning is disabled (note: the class was initially disabled due to memory usage concerns)
  • ran the kernel after reverting to blocks without stored state and confirmed that the genesis was rebuilt and full state recovery was successful

Verification

Insert x into the following checkboxes to confirm (eg. [x]):

  • I have self-reviewed my own code and conformed to the style guidelines of this project.
  • New and existing tests pass locally with my changes.
  • I have added tests for my fix or feature.
  • I have made appropriate changes to the corresponding documentation.
  • My code generates no new warnings.
  • Any dependent changes have been made.

Copy link
Collaborator

@AionJayT AionJayT left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

few performance enhancement comments.

this.repository.getBlockStore().saveBlock(genesis, genesis.getCumulativeDifficulty(), true);
LOG.info("Rebuilding genesis block SUCCEEDED.");
}

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

how about extract this code snippet to a mathod?

} else if (ref != null) {
ref.dbRef = false;
}
}
src.putBatch(batchRemove);
src.deleteBatch(batchRemove);
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

how many keys need to be removed during the prune? if it's a lot, use parallel-stream to shorten the processing time instead of the for loop?

return;
}
// deletes are delayed
keys.forEach(key -> currentUpdates.deletedKeys.add(new ByteArrayWrapper(key)));
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

same here. can we do parallel?

@AlexandraRoatis
Copy link
Contributor Author

I think the batch sizes are too small to need parallelism here at present.


LOG.info("Rebuilding genesis block SUCCEEDED.");
}

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What if buildGenesis fails? Do we need any log message here?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

if there is anything wrong with the genesis file an error message will be printed before recovery is attempted

@@ -76,7 +76,12 @@ protected AionRepositoryImpl(IRepositoryConfig repoConfig) {
// repository singleton instance
private final static AionRepositoryImpl inst = new AionRepositoryImpl(
new RepositoryConfig(new File(config.getBasePath(), config.getDb().getPath()).getAbsolutePath(),
-1,
config.getDb().getPrune() > 0 ?
// if the value is smaller than backward step
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pruning value should dictate parameters for our sync. So if we set a value of 16 as our pruning parameter, sync should respect that value.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the interaction between pruning and sync is tuned in #498

"Corrupt world state for genesis block hash: " + genesis.getShortHash() + ", number: " + genesis
.getNumber() + ".");

buildGenesis(genesis);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

buildGenesis() seems to be building the genesis state based on the current repository. It's correct for the latter usage, when the database is empty, but is it still valid here?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it's valid, i.e. it always results in the same state root, because when calling createAccount(Address) the stateRoot = EMPTY_TRIE_HASH;, so it does not build on the state root of the tracked repository

@AionJayT AionJayT merged commit 8ac445d into master-pre-merge Jun 1, 2018
@AionJayT AionJayT mentioned this pull request Jun 14, 2018
10 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants