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

Retrieving logs using bloom cache #795

Merged
merged 2 commits into from Mar 29, 2019

Conversation

Projects
None yet
5 participants
@ajlopezrsk
Copy link
Contributor

commented Mar 27, 2019

These changes were tested on Testnet, using 0.6.1 release.

Out of scope: add configuration settings for number of blocks for confirmations. Now, it is hardcoded in 20 blocks. Only the logs of the confirmed blocks are added to the in-memory cache

@tinchou
Copy link
Contributor

left a comment

I think this looks good to merge. If I were coding it I would choose to make the LogFilter#processBlocks an instance method of BlocksBloomStore. There's an automatic refactor to do it:

image

After this, all the other methods of BlocksBloomStore would only accessed from tests, which means they would be exposing internal implementation details. I would rework those tests to only exercise the public interface, which in this case would be the BlocksBloomStore#processBlocks

@rskops

This comment has been minimized.

Copy link

commented Mar 28, 2019

SonarQube analysis reported 10 issues

  1. MAJOR RskFactory.java#L359: java/nio/file/Paths.get(Ljava/lang/String;[Ljava/lang/String;)Ljava/nio/file/Path; reads a file whose location might be specified by user input rule
  2. MAJOR RskFactory.java#L360: java/nio/file/Paths.get(Ljava/lang/String;[Ljava/lang/String;)Ljava/nio/file/Path; reads a file whose location might be specified by user input rule
  3. MAJOR RskFactory.java#L366: java/io/FileOutputStream.(Ljava/lang/String;)V writes to a file whose location might be specified by user input rule
  4. MAJOR RskFactory.java#L534: Either log or rethrow this exception. rule
  5. MAJOR RskFactory.java#L707: java/io/File.(Ljava/lang/String;)V reads a file whose location might be specified by user input rule
  6. MAJOR LogFilter.java#L213: Refactor this code to not nest more than 3 if/for/while/switch/try statements. rule
  7. MAJOR LogFilter.java#L217: Refactor the code in order to not assign to this loop counter from within the loop body. rule
  8. MINOR BitSet.java#L65: Return a copy of "bytes". rule
  9. MINOR Bloom.java#L47: Store a copy of "data". rule
  10. MINOR Bloom.java#L79: Return a copy of "data". rule
@ajlopezrsk

This comment has been minimized.

Copy link
Contributor Author

commented Mar 29, 2019

BlocksBloomStore has no reference to a block. Moving this logic to BlocksBloomStore could infect it with new responsabilities, that live better in LogFilter.

The log filter logic could be rewritten, but it is out of scope for this pull request

I think this looks good to merge. If I were coding it I would choose to make the LogFilter#processBlocks an instance method of BlocksBloomStore. There's an automatic refactor to do it:

image

After this, all the other methods of BlocksBloomStore would only accessed from tests, which means they would be exposing internal implementation details. I would rework those tests to only exercise the public interface, which in this case would be the BlocksBloomStore#processBlocks

@tinchou
Copy link
Contributor

left a comment

OK, looks good!

@aeidelman aeidelman merged commit 884226e into master Mar 29, 2019

3 checks passed

ci/circleci Your tests passed on CircleCI!
Details
default Build finished.
Details
sonarqube SonarQube reported 10 issues, no criticals or blockers

@aeidelman aeidelman deleted the logbitsmaster branch Mar 29, 2019

@aeidelman aeidelman added this to the Orchid v0.6.2 milestone Apr 19, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.