raboof/pekko
1
0
Fork 0
Code Issues Pull requests Projects Releases 6 Packages Wiki Activity Actions 10

Low level interpreter tests working without GraphAssembly #22423

Browse source
This commit is contained in:
Johan Andrén 2017-03-07 17:06:41 +01:00 • committed by GitHub
parent 44260fe5d3
commit c028b550f2
26 changed files with 354 additions and 575 deletions
Download patch file Download diff file Expand all files Collapse all files

13
akka-docs/rst/scala/code/docs/stream/FlowDocSpec.scala
View file

@ -220,19 +220,6 @@ class FlowDocSpec extends AkkaSpec {
//#flow-mat-combine
}
"explicit fusing" in {
//#explicit-fusing
import akka.stream.Fusing
val flow = Flow[Int].map(_ * 2).filter(_ > 500)
val fused = Fusing.aggressive(flow)
Source.fromIterator { () => Iterator from 0 }
.via(fused)
.take(1000)
//#explicit-fusing
}
"defining asynchronous boundaries" in {
//#flow-async
Source(List(1, 2, 3))

9
akka-docs/rst/scala/code/docs/stream/GraphDSLDocSpec.scala
View file

@ -115,15 +115,6 @@ class GraphDSLDocSpec extends AkkaSpec {
priorityJobsIn.carbonCopy(),
resultsOut.carbonCopy())
// A Shape must also be able to create itself from existing ports
override def copyFromPorts(
inlets: immutable.Seq[Inlet[_]],
outlets: immutable.Seq[Outlet[_]]) = {
assert(inlets.size == this.inlets.size)
assert(outlets.size == this.outlets.size)
// This is why order matters when overriding inlets and outlets.
PriorityWorkerPoolShape[In, Out](inlets(0).as[In], inlets(1).as[In], outlets(0).as[Out])
}
}
//#graph-dsl-components-shape

19
akka-docs/rst/scala/stream/stream-flows-and-basics.rst
View file

@ -229,24 +229,17 @@ which will be running on the thread pools they have been configured to run on -
Operator Fusion
---------------
Akka Streams 2.0 contains an initial version of stream operator fusion support. This means that
the processing steps of a flow or stream graph can be executed within the same Actor and has three
consequences:
By default Akka Streams will fuse the stream operators. This means that the processing steps of a flow or
stream graph can be executed within the same Actor and has two consequences:
* starting up a stream may take longer than before due to executing the fusion algorithm
* passing elements from one processing stage to the next is a lot faster between fused
stages due to avoiding the asynchronous messaging overhead
* fused stream processing stages no longer run in parallel to each other, meaning that
* fused stream processing stages does not run in parallel to each other, meaning that
only up to one CPU core is used for each fused part
The first point can be countered by pre-fusing and then reusing a stream blueprint as sketched below:
.. includecode:: ../code/docs/stream/FlowDocSpec.scala#explicit-fusing
In order to balance the effects of the second and third bullet points you will have to insert asynchronous
boundaries manually into your flows and graphs by way of adding ``Attributes.asyncBoundary`` using the method
``async`` on ``Source``, ``Sink`` and ``Flow`` to pieces that shall communicate with the rest of the graph in an
asynchronous fashion.
To allow for parallel processing you will have to insert asynchronous boundaries manually into your flows and
graphs by way of adding ``Attributes.asyncBoundary`` using the method ``async`` on ``Source``, ``Sink`` and ``Flow``
to pieces that shall communicate with the rest of the graph in an asynchronous fashion.
.. includecode:: ../code/docs/stream/FlowDocSpec.scala#flow-async