 = 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()!
}!
})!
} https://github.com/rkuhn/ReactiveStreamsInterop](https://image.slidesharecdn.com/akkastreams-150418090358-conversion-gate01/85/Akka-streams-11-320.jpg)
![Back-pressure? Example Without
Publisher[T] Subscriber[T]](https://image.slidesharecdn.com/akkastreams-150418090358-conversion-gate01/85/Akka-streams-26-320.jpg)
Akka streams
- 1. Mirco Dotta @mircodotta Akka Streams Asynchronous non-blocking streaming made easy
- 2. Cascata Piumogna a Faido
- 3. Reactive Applications The Four Reactive Traits http://reactivemanifesto.org/
- 5. Why Reactive? • Users expectations have changed • Services must be always up. • Must be fast. • Billions of internet connected devices. • Data is transformed and pushed continuously.
- 6. Reactive Streams An initiative for providing Standardised(!) Back-pressured Asynchronous Stream processing ! http://www.reactive-streams.org/
- 7. Reactive Streams: Who? ! • Kaazing • Netflix (rxJava) • Pivotal (reactor) • RedHat (vert.x) • Twitter • Typesafe (akka-streams & slick) • Doug Lea proposed an implementation for JDK9! ! !
- 9. Reactive Streams: Inter-op ! We want to make different implementations co-operate with each other.
- 10. Reactive Streams: Inter-op The different implementations “talk to each other” using the Reactive Streams protocol.
- 11. Reactive Streams: Inter-op // here are a few imports that you are not seeing! object ScalaMain extends App {! 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()! }! })! } https://github.com/rkuhn/ReactiveStreamsInterop
- 12. Reactive Streams: Inter-op The Reactive Streams SPI is NOT meant to be user- api. You should use one of the implementing libraries.
- 13. Akka Streams
- 14. Akka Streams: Basics • DSL for the formulation of transformations on data streams. • Basic building blocks: • Source -‐ something with exactly one output stream. • Flow - something with exactly one input and one output stream. • Sink - something with exactly one input stream. • RunnableFlow - A Flow that has both ends “attached” to a Source and Sink respectively, and is ready to be run() .
- 18. Demo 1
- 19. Akka Streams: Graph • Source, Flow, and Sink are good for expressing linear computations. • But how to express a computation graph?
- 20. Demo 2
- 21. Akka Streams: Fan-out • Broadcast -‐ given an input element emits to each output. • Balance- given an input element emits to one of its output ports. • UnZip - splits a stream of (A,B) tuples into two streams, one of type A and on of type B. • FlexiRoute -‐ enables writing custom fan out elements using a simple DSL.
- 22. Akka Streams: Fan-in • Merge -‐ picks randomly from inputs pushing them one by one to its output. • MergePreferred - like Merge but if elements are available on preferred port, it picks from it, otherwise randomly from others. • ZipWith(fn)- takes a function of N inputs that given a value for each input emits 1 output element.
- 23. Akka Streams: Fan-in cont’d • Zip - is a ZipWith specialised to zipping input streams of A and B into an (A,B) tuple stream. • Concat - concatenates two streams (first consume one, then the second one). • FlexiMerge - enables writing custom fan-in elements using a simple DSL.
- 24. Demo 3
- 26. Back-pressure? Example Without Publisher[T] Subscriber[T]
- 27. Back-pressure? Example Without Fast Publisher Slow Subscriber
- 28. Back-pressure? “Why would I need that!?”
- 29. Back-pressure? Push + NACK model
- 30. Back-pressure? Push + NACK model Subscriber usually has some kind of buffer.
- 31. Back-pressure? Push + NACK model
- 32. Back-pressure? Push + NACK model
- 33. Back-pressure? Push + NACK model What if the buffer overflows?
- 34. Back-pressure? Push + NACK model (a) Use bounded buffer, drop messages + require re-sending
- 35. Back-pressure? Push + NACK model (a) Kernel does this! Routers do this! (TCP) Use bounded buffer, drop messages + require re-sending
- 36. Back-pressure? Push + NACK model (b) Increase buffer size… Well, while you have memory available!
- 37. Back-pressure? Push + NACK model (b)
- 39. Back-pressure? Example NACKing Buffer overflow is imminent!
- 40. Back-pressure? Example NACKing Telling the Publisher to slow down / stop sending…
- 41. Back-pressure? Example NACKing NACK did not make it in time, because M was in-flight!
- 42. Back-pressure? NACKing is NOT enough.
- 44. Back-pressure? Fast Subscriber, No Problem No problem!
- 46. Just push – not safe when Slow Subscriber ! ! Just pull – too slow when Fast Subscriber Back-pressure? RS: Dynamic Push/Pull
- 47. ! ! ! Solution: Dynamic adjustment Back-pressure? RS: Dynamic Push/Pull Just push – not safe when Slow Subscriber ! ! Just pull – too slow when Fast Subscriber
- 48. Back-pressure? RS: Dynamic Push/Pull Slow Subscriber sees it’s buffer can take 3 elements. Publisher will never blow up it’s buffer.
- 49. Back-pressure? RS: Dynamic Push/Pull Fast Publisher will send at-most 3 elements. This is pull-based-backpressure.
- 50. Back-pressure? RS: Dynamic Push/Pull Fast Subscriber can issue more Request(n), before more data arrives!
- 51. Back-pressure? RS: Dynamic Push/Pull Fast Subscriber can issue more Request(n), before more data arrives. ! Publisher can accumulate demand.
- 52. Back-pressure? RS: Accumulate demand Publisher accumulates total demand per subscriber.
- 53. Back-pressure? RS: Accumulate demand Total demand of elements is safe to publish. Subscriber’s buffer will not overflow.
- 54. Demo 4
- 55. Is that really all there is to know? • Naaaa, there is a lot more for you to explore! • If the existing building blocks are not enough, define your owns. • Use mapAsync/mapAsyncUnordered for integrating with external services. • Streams Error Handling. • Handling TCP connections with Streams. • Integration with Actors.
- 56. What now? • Use it: "com.typesafe.akka" %% "akka-stream-experimental" % "1.0-M5" • Check out the Activator template Akka Streams with Java8orScala. • Akka Streams API doc and user guide for both Java8 and Scala. • Code used for the demos https://github.com/ dotta/akka-streams-demo/releases/tag/v01
- 57. Next Steps • Akka Streams RC1 soon (before end of April). • Inclusion in future JDK (shooting for JDK9) • We aim at polyglot standard (JS, wire proto) • Try it out and give feedback! • http://reactive-streams.org/ • https://github.com/reactive-streams
- 59. ©Typesafe 2015 – All Rights Reserved