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

Fix eager execution due to flatMap #5430

Merged
merged 3 commits into from
Sep 17, 2019

Conversation

flyingsilverfin
Copy link
Member

@flyingsilverfin flyingsilverfin commented Sep 17, 2019

What is the goal of this PR?

We currently have a use of flatMap() on the stream of answers that is produced from Janus via our various transformations to produce Concepts and Answers. The flatMap() at the end of this sequence of stream manipulations is not necessarily lazy.

See:
https://bugs.openjdk.java.net/browse/JDK-8075939

To fix this we introduced Vavr which is able to properly handle lazy streams and flatMap operations. We introduce a minimal change using this library as required here, converting to a Vavr stream and back once the flatMap is added to the stream.

What are the changes implemented in this PR?

  • Introduce a light dependency io.vavr.vavr that has no transitive dependencies beyond one of its own further packages
  • Replace flatMap in QueryExecutor.match with a few steps to utilise vavr's stream implementation that actually lazy

@flyingsilverfin flyingsilverfin merged commit fd2d3b7 into vaticle:master Sep 17, 2019
@lolski lolski added this to the 1.5.9 milestone Sep 17, 2019
@lolski
Copy link
Member

lolski commented Sep 17, 2019

@flyingsilverfin LGTM! don't forget to set the appropriate labels and milestone next time ;)

@flyingsilverfin flyingsilverfin self-assigned this Sep 17, 2019
flyingsilverfin added a commit that referenced this pull request Sep 26, 2019
## What is the goal of this PR?
Replace io.vavr (#5430) that was introduced to solve the lack of lazy `flatMap` that is mentioned in #5430. We then determined that conversion to the `io.vavr` Stream implementation is more lazy, but the conversion step itself does a single call to `.next()`. In practical terms, this means Grakn always precomputed the first answer on query, which is still not fully lazy.
This led to the decision to restore prior behavior and solve the eagerness problem by implementing our own lazy stream merging solution.

## What are the changes implemented in this PR?
* Implement a lazy stream merging solution that uses `stream.iterator()` conversions interally
* Remove `io.vavr` as a dependency
* tests for lazy stream merging
@flyingsilverfin flyingsilverfin deleted the eager-flatmap branch December 7, 2020 11:17
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants