We’re modifying our example by adding multiple stages of computations: We already know that the stream will run on a different thread, but it is not clear yet how different pieces/computations of pipelines execute. This has significance and will be explained later.) (Observant readers probably noted the number “5” as the last character of the name of the thread. Streams do not run on the caller thread, instead, they run on a different thread in the background, without blocking the caller.We stopped the ActorSystem running the stream before it even had the chance to execute. First, the stream that prints “Hello Stream World” is running on a different thread ( -dispatcher-5) and it is not blocking our main thread since the main thread printed “running” before the stream has completely finished. We immediately get an answer why our previous attempts failed. In this post I assume some familiarity with the concepts explained in the linked documentation page.Īs our first step, let’s try a simple experiment and see if we can figure out how computations are mapped to threads: For more details on the role of modularity I recommend this section in the documentation: An Iterator always executes any chained computations on the caller thread.
In this view, a Source is not a static collection of elements not like an Iterator, because computations can happen asynchronously, working concurrently with other computations. In Akka Streams, we mostly think in terms of computations -“boxes” that can accept and emit elements of a certain type in sequence on their various ports. Implicit val materializer = ActorMaterializer.create(system) Val system = ActorSystem("LifecycleDemo") Always use the latest minor release – 2.4.7 as of writing this blog post.:
#Akka multi counter code#
In this post, I will explore how Akka Streams processing pipelines or graphs are transformed to actual multi-threaded execution.Īll of the code in the post assumes the akka-stream artifact of at least version 2.4.2 to be present, and the following code implicitly being present in all samples. That can safely interact with various forms of non-blocking IO interfacesĪnd solving the typical pitfall of missing backpressure: faster producers overwhelm slower consumers that run on a separate thread, resulting in OutOfMemoryExceptions. The primary goal of streams is to provide a simple way to:īuild concurrent and memory bounded computations Akka Streams and streaming has different meaning to different people, but my view is that it is mostly a concurrency construct, like Actors and Futures.
0 kommentar(er)
