docs: make docs clearer for groupBy operator #24671#32273
docs: make docs clearer for groupBy operator #24671#32273johanandren merged 1 commit intoakka:mainfrom
Conversation
akka-docs/src/main/paradox/stream/operators/Source-or-Flow/groupBy.md
Outdated
Show resolved
Hide resolved
dhirensr
force-pushed
the
issue_24671
branch
2 times, most recently
from
9b8cd7b to
c62fd60
Compare
|
@johanandren : changed the text, can you please review again? |
| // #groupByWithAsync | ||
| Source.range(1, 10) | ||
| .groupBy(2, i -> i % 2 == 0) // create two sub-streams with odd and even numbers | ||
| .async() |
There was a problem hiding this comment.
This is trickily enough not the right thing, .async() creates an async boundary between the graph so far and the next steps, to create a separate async island for each substream you would have to do .via(Flow.reduce(...).async())
There was a problem hiding this comment.
ah gotcha! I wasn't aware about this, and maybe I've been using it wrongly. I'll update the example.
@johanandren : just to confirm adding async between groupBy and flow is kind of redundant then and has no impact? wondering if it should even compile if it's redundant because it's misleading
There was a problem hiding this comment.
Just groupBy().async would put the graph up to that point, so Source.range and groupBy grouping on one stream interpreter actor, and then all the downstreams and the substream merge and sink would run in another single actor. So it has impact but it does not do what we want to show here (one separate stream interpreter per substream).
There was a problem hiding this comment.
@johanandren : does this diagram depict the right understanding ? before making the change I wanted to understand correctly.
I think the current example is state A and we want to show state B in the example by adding async to the flow before merging sub streams. correct?
There was a problem hiding this comment.
Just doing .async after groupBy means that you end up with two interpreters/actors running the stream, one up to the .async and one after.
State B is correct, Flow.a.b.b.async adds a boundary around each materialisation of that flow
There was a problem hiding this comment.
@johanandren : the image you attached is the current state right ? and State B which is correct will be done by adding async in the example as proposed by you , right?
also the materialisation of the stream happens even between the actors or only at the end of the stream?
There was a problem hiding this comment.
Yes, exactly, my drawing is what happens with the current (instead of your suggested State A), State B in the diagram is the fixed Flow().async one.
The materialization, turning a stream graph/bluepring into a running stream, of the sub stream happens each time a new group-by key is seen, however, normally the sub stream is materialized into the existing running stream. The async boundary around it means materialized stream becomes a separately running stream.
There was a problem hiding this comment.
Thanks for the answer @johanandren. I've now changed the example as suggested, can you please review it again?
2 participants
related to #24671