Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Reactive Programming

Reactive Programming

Presentation held at the Parallel Conference in Karlsruhe, Germany, on May 6, 2014. Apart from the slides, the presentation featured a demo of RxJava, highlighting its strengths and some of its current limitations.

Patrick Peschlow

May 06, 2014

More Decks by Patrick Peschlow

Other Decks in Technology


  1. codecentric AG Event-driven Trait − Asynchronous − Synchronous APIs tightly

    couple client and service (often block) − Asynchronous means the client can decide if and where to block ! − Non-blocking − Blocking APIs may require large numbers of threads (often coupled to users) − Wastes CPU resources (context switches, scheduling) − Non-blocking frees threads to do new work − Define worker thread pools based on resources ! − Share nothing ! − Loose coupling Based on: Roland Kuhn, Jamie Allen. „Reactive Design Patterns“. Manning. Chapter 1 preview.
  2. codecentric AG Example Time Scale of System Latencies From: Brendan

    Gregg. „Systems Performance: Enterprise and the Cloud“. Prentice Hall, 2013
  3. codecentric AG Futures and Promises − Future: A reference to

    an asynchronously computed value ! − Promise: A future with additional features − May be completed in various ways (e.g., by a setter) − Enables composition (one promise completes another) ! − (Functional) Reactive Programming − Futures and promises taking to the extreme
  4. codecentric AG RxJava Reactive Extensions for the JVM — A

    library for composing
 asynchronous and event-based programs using observable sequences for the Java VM From: http://github.com/Netflix/RxJava
  5. codecentric AG Observable single items multiple items synchronous T  getData()

    Iterable<T>  getData() asynchronous Future<T>  getData() Observable<T>  getData() From: http://github.com/Netflix/RxJava/wiki
  6. codecentric AG Observable From: http://github.com/Netflix/RxJava/wiki Iterable (pull) Observable (push) T

     next() onNext(T) throws Exception onError(Exception) returns onCompleted()
  7. codecentric AG Benefits of Observables − Life cycle of client

    and service are decoupled ! − Service API keeps control over its implementation ! − Client decides how its subscription should behave (e.g., timeouts) ! − Note: The „client“ may be another service having its own clients − Not necessarily a human or a browser
  8. codecentric AG Back Pressure − An eager producer can overflow

    its consumer(s) − Due to inversion of control when going from sync to async ! − Consumers need a mechanism for „back pressure“ − Tell the producer how much data you can handle − Similar to, e.g., receiver window in TCP From: http://www.reactive-streams.org
  9. codecentric AG Responsive Trait − Goal: Achieve bounded latency !

    − Parallelize tasks within services ! − Choose algorithms with small variance in execution time − Predictable execution time for some target percentile ! − Use explicit and bounded queues ! − Use circuit breakers that monitor target metrics and react on violation − fail-fast and reject, return partial results, or delegate to another service − e.g., for input queues, reject requests when the queue is full Based on: Roland Kuhn, Jamie Allen. „Reactive Design Patterns“. Manning. Chapter 1 preview.
  10. codecentric AG Resilient Trait − Goal: Service stays available even

    in the presence of unexpected failures − software, hardware, human ! − Distribute the system ! − Use bulkheading ! ! ! ! − Let supervisors handle failure − separate failure handling from the actual business logic of the service Based on: Roland Kuhn, Jamie Allen. „Reactive Design Patterns“. Manning. Chapter 1 preview. From: http://www.reactivemanifesto.org
  11. codecentric AG Scalable Trait − Goal: Scale up (and down)

    based on load ! − Distribute requests to various instances of the services ! − The more stateless services, the better ! − Measure load at run time and react accordingly − But: No reason to forego capacity planning Based on: Roland Kuhn, Jamie Allen. „Reactive Design Patterns“. Manning. Chapter 1 preview.
  12. codecentric AG What about Actors? − Seem to fulfill the

    reactive traits much better than reactive programming does − Asynchronous, non-blocking, and event-driven by definition − Supervisors and „let it crash“ − Distributed − Easily scalable ! − But maybe too „heavyweight“ for some problems within services − Often, stateless actors don’t suffice or get highly complex ! − Promising approach: Combine actors and reactive programming − Actors for the backbone and cluster „infrastructure“ − Reactive Programming inside the nodes
  13. codecentric AG Conclusion − Clear need for reactive applications !

    − Well addressed by the actor model and reactive programming approaches ! − Building reactive applications requires different thinking ! − Helped by various reactive frameworks, in particular on the JVM ! − Brings up the topic of essential complexity vs. incidental complexity
  14. codecentric AG Frameworks − Reactive Extensions (Rx)
 http://rx.codeplex.com ! −

 http://github.com/Netflix/RxJava ! − Akka
 http://akka.io ! − Vert.x
 http://vertx.io ! − Reactor
  15. codecentric AG Resources − Reactive Manifesto
 http://www.reactivemanifesto.org ! − Reactive

 http://www.reactive-streams.org ! − Conference „React 2014“
 http://www.youtube.com/user/reactconf ! − Online course on Reactive Programming
 http://www.coursera.org/course/reactive ! − Roland Kuhn, Jamie Allen. „Reactive Design Patterns“. Manning. Currently in writing. ! − Michael Nygard. „Release It!“. Pragmatic Bookshelf. 2007.
  16. codecentric AG Questions? Dr. rer. nat. Patrick Peschlow
 codecentric AG

    Merscheider Straße 1
 42699 Solingen
 tel +49 (0) 212.23 36 28 54
 fax +49 (0) 212.23 36 28 79
 [email protected]
  17. codecentric AG Bonus: What does this mean for my (Big)

    Data? − If reactive applications focus so much on availability, what about consistency − CAP suggests you need to choose between C and A ! − But: Even with CAP you can have C and A most of the time − You just need to have a reliable strategy for detecting and handling partitions − http://www.infoq.com/articles/cap-twelve-years-later-how-the-rules-have-changed ! − Note: There is also a „Reactive Programming“ in the context of databases − http://www.espressologic.com/reactive-programming-database-logic/ − Don’t confuse it with the „Functional Reactive Programming“ we have seen