Skip to content
Go to file

Latest commit


Git stats


Failed to load latest commit information.
Latest commit message
Commit time


Notes on Reactive Programming

Basics of Reactive Programming in Java

Concurrent Programming with Spring Reactive

Appendix: Server Platform Comparison

TODO: more chat to tidy up

such a solution will only get you so far

not to mention that it is still byte[]-based, and does not expose ByteBuffers in any way

to be honest, there is no way to answer your question yet, as we haven’t done any serious performance testing. But we ​*expect*​ Netty to be a better fit, since its threading model is more close aligned to a reactive world. Servlet containers still use a one-thread-per-request model, even if you are using the async support

so threading is reason one, exposing byte buffers is reason two for preferring netty

David Syer [11:03 AM]
But buffers are just more efficient?

Because of heap memory?

Arjen Poutsma [11:03 AM]

and non-blockingness of the java.nio API

The Role of Back Pressure

  • subscribeOn() allows a Flux to relay a slow publisher

  • publishOn() allows a Flux to have slow subscribers

TODO: tidy this up…​

since callback is called for each subscriber you can use operators that share a context

Mono.defer( () -> {
  AtomicInteger d = new AtomicNumber();
  return Mono.just(1)

d here is scoped for a given Subscriber that can be useful

Don’t Be the Bottleneck

Microbenchmarks always show that, as long as no-one blocks a thread, data flows faster if we match the number of threads to the number of cores (possibly with an extra core dispatching thread). That’s why the thread pools created by Reactor by default limit themselves to the number of available processors, and it’s why Reactor is frugal with threads, never jumping a thread boundary unless explicitly instructed.

Do you need to know all this stuff? Possibly not. You can be the bottleneck, if you are confident that you are no worse than your downstream dependencies. You might as well stick with plain old imperative programming and synchronous request-response. Use a few background threads to grease your way a bit. The result is easier to understand and easier to operationalize.

Readable (but unfortunately database-biased) article: How is Reactive Programming Different?

Blog from RxJava lead David Karnok including the one on Generations of Reactive

Reactive Gems github issue with documentation of lots of use cases you can think of as state)[Continuation - Wikipedia]

A multilingual framework (including Java): Sodium - GitHub

Sebastien Deleuze’s Reactive Types Blog


No description, website, or topics provided.



No releases published


No packages published


You can’t perform that action at this time.