Reactive Stream Processing with Akka Streams

Konrad 'ktoso' Malawski
GeeCON 2014 @ Kraków, PL
Konrad `@ktosopl` Malawski
streams
reactive stream processing
with

Akka Team
Reactive Streams TCK
sbt-jmh
…
hAkker @

typesafe.com
geecon.org
Java.pl / KrakowScala.pl
sckrk.com / meetup.com/Paper-Cup @ London
GDGKrakow.pl
meetup.com/Lambda-Lounge-Krakow
hAkker @

Agenda
• Reactive Streams
• Background and Speciﬁcation
• Protocol details
• Akka Streams
• Concepts and goals
• Building Blocks
• Akka Streams in Action
• Q & A

Streams
“You cannot enter the same river twice”
~ Heraclitus
http://en.wikiquote.org/wiki/Heraclitus

Streams
Real Time Stream Processing
When you attach “late” to a Publisher,
you may miss initial elements – it’s a river of data.
http://en.wikiquote.org/wiki/Heraclitus

Reactive Streams
Stream processing

Reactive Streams
Back-pressured
Stream processing

Reactive Streams
Back-pressured
Asynchronous
Stream processing

Reactive Streams
Back-pressured
Asynchronous
Stream processing
Standardised (!)

Reactive Streams: Goals
1. Back-pressured Asynchronous Stream processing
2. Standard implemented by many libraries

Reactive Streams - Specification & TCK
http://reactive-streams.org

Reactive Streams - Who?
Kaazing Corp.
rxJava @ Netﬂix,
reactor @ Pivotal (SpringSource),
vert.x @ Red Hat,
Twitter,
akka-streams @ Typesafe,
spray @ Spray.io,
Oracle,
java (?) – Doug Lea - SUNY Oswego
…

Reactive Streams - Inter-op
We want to make different implementations
co-operate with each other.

The different implementations “talk to each other”
using the Reactive Streams protocol.

The Reactive Streams SPI is NOT meant to be user-api.
You should use one of the implementing libraries.

package com.rolandkuhn.rsinterop
import ratpack.rx.RxRatpack
import ratpack.test.embed.EmbeddedApp
import ratpack.handling.Handler
import ratpack.handling.Context
import rx.Observable
import scala.collection.JavaConverters._
import akka.stream.scaladsl.Flow
import akka.stream.scaladsl.Source
import rx.RxReactiveStreams
import akka.stream.scaladsl.Sink
import akka.actor.ActorSystem
import akka.stream.FlowMaterializer
import ratpack.http.ResponseChunks
import java.util.function.Consumer
import ratpack.test.http.TestHttpClient
import reactor.rx.Streams
object ScalaMain extends App {
val system = ActorSystem("InteropTest")
implicit val mat = FlowMaterializer()(system)

EmbeddedApp.fromHandler(new Handler {
override def handle(ctx: Context): Unit = {
// RxJava Observable
val intObs = Observable.from((1 to 10).asJava)
// Reactive Streams Publisher
val intPub = RxReactiveStreams.toPublisher(intObs)
// Akka Streams Source
val stringSource = Source(intPub).map(_.toString)
// Reactive Streams Publisher
val stringPub = stringSource.runWith(Sink.fanoutPublisher(1, 1))
// Reactor Stream
val linesStream = Streams.create(stringPub).map[String](new reactor.function.Function[String, String] {
override def apply(in: String) = in + "n"
})
// and now render the HTTP response (RatPack)
ctx.render(ResponseChunks.stringChunks(linesStream))
}
}).test(new Consumer[TestHttpClient] {
override def accept(client: TestHttpClient): Unit = {
val text = client.getText()
println(text)
system.shutdown()
}
})
}

Back-pressure? Example Without
Publisher[T] Subscriber[T]

Back-pressure? Example Without
Fast Publisher Slow Subscriber

Back-pressure?
“Why would I need that!?”

Back-pressure? Push + NACK model

Subscriber usually has some kind of buffer.

What if the buffer overﬂows?

Back-pressure? Push + NACK model (a)
Use bounded buffer,
drop messages + require re-sending

Back-pressure? Push + NACK model (a)
Kernel does this!
Routers do this!
(TCP)
Use bounded buffer,
drop messages + require re-sending

Back-pressure? Push + NACK model (b)
Increase buffer size…
Well, while you have memory available!

Back-pressure? Push + NACK model (b)

Back-pressure?
NACKing is NOT enough.

Back-pressure? Example NACKing
Buffer overﬂow is imminent!

Telling the Publisher to slow down / stop sending…

NACK did not make it in time,
because M was in-ﬂight!

Back-pressure?
speed(publisher) < speed(subscriber)

Back-pressure? Fast Subscriber, No Problem
No problem!

Back-pressure?
Reactive-Streams
=
“Dynamic Push/Pull”

Just push – not safe when Slow Subscriber
Just pull – too slow when Fast Subscriber
Back-pressure? RS: Dynamic Push/Pull

Solution:
Dynamic adjustment
Just push – not safe when Slow Subscriber
Just pull – too slow when Fast Subscriber

Slow Subscriber sees it’s buffer can take 3 elements.
Publisher will never blow up it’s buffer.

Fast Publisher will send at-most 3 elements.
This is pull-based-backpressure.

Fast Subscriber can issue more Request(n),
before more data arrives!

Fast Subscriber can issue more Request(n),
before more data arrives.
Publisher can accumulate demand.

Back-pressure? RS: Accumulate demand
Publisher accumulates total demand per subscriber.

Back-pressure? RS: Accumulate demand
Total demand of elements is safe to publish.
Subscriber’s buffer will not overﬂow.

Back-pressure? RS: Requesting “a lot”
Fast Subscriber can issue arbitrary large requests,
including “gimme all you got” (Long.MaxValue)

MAX
speed

Easy
MAX
speed

Pipelining in Reactive Streams

A Publisher may be able
to pre-generate some data…

Request(5)

…and since signalling happens asynchronously…

pending demand pending demand
reserve buffer space

signal demand
buffer space for
incoming elements

The goal here is to never wait, unless back-pressured.

Reactive Streams SPI
public interface Publisher<T> {
public void subscribe(Subscriber<? super T> s);
}

}
gives a public interface Subscription {
public void request(long n);
public void cancel();
}
A

public interface Subscriber<T> {
public void onSubscribe(Subscription s);
public void onNext(T t);
public void onError(Throwable t);
public void onComplete();
}
}
gives a
to a
public interface Subscription {
public void request(long n);
public void cancel();
}

Akka
Akka has multiple modules:
akka-actor: actors (concurrency abstraction)
akka-remote: remote actors
akka-cluster: clustering
akka-persistence: CQRS / Event Sourcing
akka-camel: integration
akka-streams: stream processing
…

Akka
Akka is a high-performance concurrency
library for Scala and Java.
At it’s core it focuses on the Actor Model:

An Actor can only:
• Send and receive messages
• Create Actors
• Change it’s behaviour
Akka
Akka is a high-performance concurrency
library for Scala and Java.
At it’s core it focuses on the Actor Model:

class Player extends Actor {
def receive = {
case NextTurn => sender() ! decideOnMove()
}
def decideOnMove(): Move = ???
}
Akka

Akka
Akka has multiple modules:
akka-actor: actors (concurrency abstraction)
akka-camel: integration
akka-remote: remote actors
akka-cluster: clustering
akka-persistence: CQRS / Event Sourcing
akka-streams: stream processing
…

Akka Streams – design decisions
Superior:
• reusability
• expansibility
• performance
• bound buffer space
• Java and Scala APIs

Akka Streams – bounded buffer space
Why reasoning about buffer space is a big deal:

Akka Streams – Linear Flow
Flow[Double].map(_.toInt). [...]
No Source attached yet.
“Pipe ready to work with Doubles”.

implicit val sys = ActorSystem("tokyo-sys")
An ActorSystem is the world in which Actors live in.
AkkaStreams uses Actors, so it needs ActorSystem.

implicit val mat = FlowMaterializer()
Contains logic on HOW to materialise the stream.

A materialiser chooses HOW to materialise a Stream.
The Flow’s AST is fully “lifted”.
The Materialiser can choose to materialise the Flow in any way it sees ﬁt.
Our implementation uses Actors.
But you could easily plug in an SparkMaterializer!

You can conﬁgure it’s buffer sizes etc.

val foreachSink = Sink.foreach[Int](println)
val mf = Source(1 to 3).runWith(foreachSink)

val foreachSink = Sink.foreach[Int](println)
val mf = Source(1 to 3).runWith(foreachSink)(mat)
Uses the implicit FlowMaterializer

// sugar for runWith
Source(1 to 3).foreach(println)

val mf = Flow[Int].
map(_ * 2).
runWith(Sink.foreach(println))
// is missing a Source,
// can NOT run == won’t compile!

val f = Flow[Int].
map(_ * 2).
runWith(Sink.foreach(i => println(s"i = $i”))).
// needs Source to run!

val f = Flow[Int].
map(_ * 2).
f.connect(Source(1 to 10)).run()

val f = Flow[Int].
map(_ * 2).
f.connect(Source(1 to 10)).run()
With a Source attached… it can run()

Flow[Int].
map(_.toString).
runWith(Source(1 to 10), Sink.ignore)
Connects Source and Sink, then runs

Akka Streams – Flows are reusable
f.withSource(IterableSource(1 to 10)).run()

Akka Streams <-> Actors – Advanced
val subscriber = ActorSubscriber(
system.actorOf(Props[SubStreamParent], ”parent”))
Source(1 to 100).
map(_.toString).
filter(_.length == 2).
drop(2).
groupBy(_.last).
runWith(subscriber)

Each “group” is a stream too! It’s a “Stream of Streams”.
Source(1 to 100).
map(_.toString).
drop(2).
groupBy(_.last).
runWith(subscriber)

groupBy(_.last).
GroupBy groups “11” to group “1”, “12” to group “2” etc.

groupBy(_.last).
It offers (groupKey, subStreamSource) to Subscriber
Source

groupBy(_.last).
It can then start children, to handle the sub-ﬂows!
Source

groupBy(_.last).
For example, one child for each group.
Source

Source(1 to 100).
map(_.toString).
drop(2).
groupBy(_.last).
runWith(subscriber)
The Actor, will consume SubStream offers.

Akka Streams – FlowGraph
FlowGraph

Akka Streams – FlowGraph
Linear Flows
or
non-akka pipelines
Could be another RS implementation!

Akka Streams – GraphFlow
Fan-out elements
and
Fan-in elements

// first define some pipeline pieces
val f1 = Flow[Input].map(_.toIntermediate)
val f2 = Flow[Intermediate].map(_.enrich)
val f3 = Flow[Enriched].filter(_.isImportant)
val f4 = Flow[Intermediate].mapFuture(_.enrichAsync)
// then add input and output placeholders
val in = SubscriberSource[Input]
val out = PublisherSink[Enriched]

FlowGraph { implicit b =>
import FlowGraphImplicits._
val bcast = Broadcast[Intermediate]
val merge = Merge[Enriched]
in ~> f1 ~> bcast ~> f2 ~> merge
bcast ~> f4 ~> merge ~> f3 ~> out
}

val g = FlowGraph {}
FlowGraph is immutable and safe to share and re-use!

There’s more to explore!
Topics we did explore today:
• asynchronous non-blocking back-pressure
• complex graph processing pipelines
• streams powered TCP server / client
• a sneak peek into custom elements

Topics we didn’t explore today:
• explicit buffering, and overﬂow strategies
• integrating with Akka Actors
• time-based operators (takeWhile, dropWhile, timer transforms)
• plenty additional combinators and junctions
• implementing custom processing stages and junctions

Future plans:
• API stabilisation and documentation (1.0 soon)
• Improve testability & TestKit
• Performance tuning of Streams & HTTP
• Provide more Sinks / Sources and operations
• Visualising ﬂow graphs
• great experiment by Tim Harper 
https://github.com/timcharper/reactive-viz
• Distributing computation graphs (?)

Links
• http://akka.io
• http://reactive-streams.org 
• https://groups.google.com/group/akka-user 
• Tim Harper’s awesome complex pipeline example + visualisation 
https://github.com/timcharper/reactive-viz 
• 1.0-M2 Documentation (not complete) 
http://doc.akka.io/docs/akka-stream-and-http-experimental/1.0-M2/scala.html
• Complete JavaDSL for all operations 
https://github.com/akka/akka/pulls?q=is%3Apr+javadsl

©Typesafe 2015 – All Rights Reserved
Reactive
Application
Development!
SBT in Action! Akka in Action!
Play for Scala! Play for Java! Atomic Scala!
Check out eBooks at Typesafe!!
Visit http://typesafe.com/resources/e-books to view all!!
Check out eBooks at Typesafe
Visit http://typesafe.com/resources/e-books to view all

Reactive Stream Processing with Akka Streams

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Destacado

Destacado (16)

Similar a Reactive Stream Processing with Akka Streams

Similar a Reactive Stream Processing with Akka Streams (20)

Más de Konrad Malawski

Más de Konrad Malawski (20)

Reactive Stream Processing with Akka Streams