No description, website, or topics provided.
Switch branches/tags
Nothing to show
Clone or download
Fetching latest commit…
Cannot retrieve the latest commit at this time.
Permalink
Failed to load latest commit information.
.mvn/wrapper
flux
gather
reactive
.gitignore
README.adoc
benchmarks.adoc
flux.adoc
intro.adoc
io.adoc
mvnw
mvnw.cmd
pom.xml

README.adoc

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]
yes

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)
             .map(d::incrementAndGet)
             .doOnError(d::decrementAndGet);
})

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

https://en.wikipedia.org/wiki/Continuation(which you can think of as state)[Continuation - Wikipedia]

A multilingual framework (including Java): Sodium - GitHub

Sebastien Deleuze’s Reactive Types Blog