doc: make it clear inputBuffer has no effect in sample #30332 (#30337)

This commit is contained in:
Johan Andrén 2021-07-07 15:17:57 +02:00 committed by GitHub
parent 3594faf646
commit 0559165b3d
No known key found for this signature in database
GPG key ID: 4AEE18F83AFDEB23

View file

@ -55,8 +55,8 @@ parameters.
Please note that when combining a `Flow` using that method, the termination signals are not carried
"through" as the `Sink` and `Source` are assumed to be fully independent. If however you want to construct
a `Flow` like this but need the termination events to trigger "the other side" of the composite flow, you can use
`Flow.fromSinkAndSourceCoupled` or `Flow.fromSinkAndSourceCoupledMat` which does just that. For example the cancelation of the composite flows
source-side will then lead to completion of its sink-side. Read @apidoc[Flow]'s API documentation for a
`Flow.fromSinkAndSourceCoupled` or `Flow.fromSinkAndSourceCoupledMat` which does just that. For example the cancellation
of the composite flows source-side will then lead to completion of its sink-side. Read @apidoc[Flow]'s API documentation for a
detailed explanation how this works.
The example `BidiFlow` demonstrates that internally a module can be of arbitrary complexity, and the exposed
@ -88,7 +88,7 @@ Java
: @@snip [CompositionDocTest.java](/akka-docs/src/test/java/jdocs/stream/CompositionDocTest.java) { #non-nested-flow }
It is clear however that there is no nesting present in our first attempt, since the library cannot figure out
It is clear however that there is no nesting present in our first attempt. Since the library cannot figure out
where we intended to put composite module boundaries, it is our responsibility to do that. If we are using the
DSL provided by the `Flow`, `Source`, `Sink` classes then nesting can be achieved by calling one of the
methods `withAttributes()` or `named()` (where the latter is a shorthand for adding a name attribute).
@ -311,15 +311,20 @@ of combining materialized values without nesting and hierarchy involved.
## Attributes
We have seen that we can use `named()` to introduce a nesting level in the fluid DSL (and also explicit nesting by using
`create()` from `GraphDSL`). Apart from having the effect of adding a nesting level, `named()` is actually
a shorthand for calling `withAttributes(Attributes.name("someName"))`. Attributes provide a way to fine-tune certain
aspects of the materialized running entity. For example buffer sizes for asynchronous operators can be controlled via
attributes (see @ref:[Buffers for asynchronous operators](stream-rate.md#async-stream-buffers)). When it comes to hierarchic composition, attributes are inherited
by nested modules, unless they override them with a custom value.
We have seen that we can use `named()` to introduce a nesting level in the fluid DSL and also explicit nesting by using
`create()` from `GraphDSL`. Apart from having the effect of adding a nesting level, `named()` is actually
a shorthand for calling `addAttributes(Attributes.name("someName"))`, adding the `name` attribute to the graph.
Attributes provide a way to fine-tune certain aspects of the materialized running entity. Attributes are inherited by
nested modules, unless they override them with a custom value. This means the attribute specified closest to the operator
in the graph will be the one that is in effect for that operator.
Another example of an attribute is the `inputBuffer` attribute which has the main purpose to provide control over buffer sizes
for asynchronous boundaries (see @ref:[Buffers for asynchronous operators](stream-rate.md#async-stream-buffers)).
The code below, a modification of an earlier example sets the `inputBuffer` attribute on certain modules, but not
on others:
on others. _Note_ that this is only to show how attributes inheritance works, the actual `inputBuffer` attribute does not
have any specific effect when running these streams:
Scala
: @@snip [CompositionDocSpec.scala](/akka-docs/src/test/scala/docs/stream/CompositionDocSpec.scala) { #attributes-inheritance }