reactive programming by example – live blogging from spring days

Reactive Programming by Example: Intro to Pivotal Reactor
Speaker: Victor Grazi @vgrazi
See list of all bog posts from conference

What is Reactive

  • Think in streams – but more powerful than Java 8 streams
  • reactive streams – high performance, async stream processing non-blocking back pressure – when ready to stop getting data
  • declarative
  • doesn’t vary much by language

Maven dependencies

  • reactor-core
  • reactor-test – ex: simulate waiting X seconds without actually waiting

Everything is a stream of messages – ex: events, query results, exceptions (errors aren’t special; still a message)
Publisher – Flux emits event messages (Observable in rx-java), immutable
Subscriber – gets next message and handles events on error/complete/subscribe. doOnNext() is like peek() in Java 8 for debugging

Marble diagram

  • treat events as marbles
  • Website: – can see different operations and drag marbles (on a computer; doesn’t work on iPad)

Creating a flux
Flux.fromIterable/fromArray – to transform from collection/array
Flux.range(startNumber, numberOfElementsInRange)
Flux.interval(Duration.ofSeconds(n)) – emit a value every X seconds
Flux.merge – combine streams
Flux.withLatestFrom – unlike zip, get latest available element rather than getting the “next” one
Flux.create – use lambda to create a listener with logic for publishing elements

distinctUntilChanged-only eliminate adjacent duplicates
zipWith – combine existing stream with another stream in tuples

Differences from Java streams

  • push based,not pull based
  • Attached to real time feeds
  • Conncurrent
  • Back pressure
  • Can only use once
  • Can compose streams (zip/merge)
  • Can fully work with infinite streams

Cold vs Hot Flux
Cold streams are finite, known elements. Hot streams are more realistics

Must call subscribe for anything to happen (like a terminal operator in Java 8 streams)

I learned a lot. Or reviewed a lot and learned some. Having heard this,I realize I had heard some of it before. Also, while the concepts are different than Java 8, knowing Java 8 streams really well helps retain this. The syntax similarities help. As do learning the key differences vs learning every API and not thinking about streams at all. And the demo at the end was easy to follow. This presentation reminds me of Java 8 streams in that it took me a few presentations by different people to finally grok it well.

servlet vs reactive stacks – live blogging from spring days

Servlet vs Reactive Stacks in 5 Use Cases
Speaker: Rossen Stoyanchev
See list of all blog posts from conference


  • asynch is a perception from the beholder. For example, HTTP is synchronous but looks async from the server. [i’m a little confused but i think i get the point of this example]
  • Amount of asynchronity is growing. The more you do it, the more complex it becomes
  • Puting blocking component behind a thread pool makes async because now there is a callback
  • Different to do async throughout the app vs one callback in one place

Elastic thread pool

  • absorb latency of blocking call
  • can be difficult to configure because need enough threads for the number of slow clients so can absorb lateny
  • uses memory from increasing call stack for threads especially at scale.
  • strategy works, but doesn’t scale

Event loop

  • Have only one thread
  • Model is non-blocking

This is how modern HTTP servers work – certain number worker threads and event loop delegates to them


  • brings flow control/li>
  • Scale without adding more threads

Java 9 Flow is closest built in option but need library for implementation.Ex Reactor, RxJava

Reactive Stack
Need Spring 5

  • Netty/Servlet 3.1+/Undertow
  • Reactive Streams Reactor
  • Spring WebFlux

Servlet Stack
Need Servlet 3 for async

  • Servlet container
  • Servlet API
  • Spring MVC

The use cases were live examples. It was cool that the Flux API looks like Java 8 streams code.

Showed how backpressure prevents adding more when not ready.

I like the @Tailable annotation – it shows what you can tail the results of while running.

Overall, I learned/reviewed some basics. The use cases were too fast for me to follow. Which is a sign I need to read a book about reactive. I’ve seen some presentations, but I don’t remember enough to recall all the terms fast enough to follow the code examples. That said,live demos are fun.

reactive programming for java developers – rossen stoyanchev – qcon

For more QCon posts, see my live blog table of contents.

General notes

  • Spring 5 has reactive features.
  • Maybe a third of the audience is doing something with reactive, a little more have read about it (that’s me) and a lot haven’t heard of it. Which is good given the title of this talk!
  • Moore’s law slowing down. No more free lunch from the hardware
  • Now apps more distributed/independent/cloudbased compared to 10 years ago
  • Now we expect latency
  • Thread now has to do more async things. Hit limits of scale. imperative logic more complicated.

Other approach

  • Async/non-blocking
  • Use very few threads. node.js has a single thread. Must be careful because blocking those few threads blocks the whole app
  • Reactive programming – think async. Not everything is a callback

Comparing styles

  • Imperative
    • call a method, get a result, do something with that result
  • Async
    • return a Future instead of a value. Don’t throw a checked exception because my happen in a different thread. They are asynchronous in that you can get a result later. But when you eventually call feature.get(), it throws different checked exceptions.
    • In Java 8, can return a CompletableFuture and call future.whenComplete((user, throwable) -> {})
    • If doing a findAll(), the future/completable future approach doesn’t give you a callback/return anything until all of them are ready. You can’t stream or could run out of memory.
    • Async results as stream – get one notification per data item and another for completion or error
  • Declarative
    • Focus on what, not how
    • Declare what should happen rather than focusing on callbacks
    • Java 8 stream API uses this style. It is meant for collections and pull based/usable once
    • Hot streams – latency sensitive streams, data need to be pushed for you
    • Cold streams – pull based

Reactive libraries

  • Stream like API
  • Can be used for hot/cold streams
  • Project Reactor – Similar to ReactiveX, easy to bridge to Java 8 streams. (ReactiveX is like XUnit – commonality for different languages)


  • Flux – sequence of 0 to n – equivalent of Java 8 stream – can convert to/from Java 8
  • Mono – sequence of 0 or 1 – can convert to/from CompletableFuture

Reactive streams spec

  • Back pressure – producers must not overwhelm consumers. Communicates if downstream isn’t ready for more items. Ex: a slow client like a mobile device isnt able to handle more data and server isn’t blocking
  • Small API – only 4 interfaces
  • Rules
  • Interoperability across reactive components so can compose chain

Java 9

  • Reactive streams included (the four interfaces)
    • Publisher
    • Subscriber
    • Subscription
    • Processor
  • Use a reactive library. Don’t implement the four interfaces yourself
  • subscribe() triggers the flow of data
  • “push” was missing until now. Want in JDK to have foundation
  • Classes
    • java.util.concurrent.Flow – the four interfaces
    • SubmissionPublisher – bridge to reactie streams
    • Tie-ins to CompletableFuture and Stream


  • GA release scheduled for July
  • Currently called 2.5. Might changed to 3.0

Reactive Spring MVC

  • Apps annotate controllers even now.
  • Return a Flux type.
  • Spring MVC itself needs to change a lot – called Spring Web Reactive
  • The servlet API assumes blocking. There are async workarounds. Servlet 4.0 might support reactive spring integration, but probably just the basics. Using own bridge to Servlet 3.1 in meantime.
  • Can still use Jetty/Tomcat. They are non-blocking behind the scenes.
  • Don’t need servlet container. Can use Netty.
  • HandlerMapping – change to return a Mono so can be non-blocking
  • Focusing on REST/microservices scenarios

Other reactive efforts

  • MongoDB – reactive driver
  • Couchbase – reactive driver
  • Thymeleaf – split templates into chunks and throttle to respect backpressure