Skip to content
main
Go to file
Code

Latest commit

 

Git stats

Files

Permalink
Failed to load latest commit information.
Type
Name
Latest commit message
Commit time
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

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

About

No description, website, or topics provided.

Resources

Releases

No releases published

Packages

No packages published

Languages

You can’t perform that action at this time.