Working principle of the project reactor

Question

for a while I am researching a lot about project reactor, Mono's, Flux's and I am little bit confused about the subject.

I like to tell here some assumptions about what I understand and may be you can tell me, I am on the correct path or not.

The reason I was interested with Reactive concepts and I thought it was similar to the concept called 'Continuations' at Jetty Server, which simply said, when a Jetty Server get a request, naturally that should be served via a server thread and Jetty Continuation was, if that thread goes to a waiting\blocking state, a continuation will take over waiting state and free the thread to do actual work instead of blocking and doing nothing, if continuation gets an event that work might continue, continuation will deliver the results to this thread in a fitting time.

Is for Project Reactor, is it the same principle, there lot of talk about Publish/Subscribe to Mono\Flux's and throttling but I can't clearly see the same concepts of continuation here.

Secondly, Jetty Continuation's needed the Native IO to be able to provide the functionality but Project Reactor is not a web project, so how is it realizing this sort of behavior.

Or am understanding the concepts totally wrong?

Thx for answers.

Answer 1

reactor-core is dealing with asynchronous processing and orchestration within a single JVM.

It applies non-blocking patterns so that multiple sequences of event can be processed by a single thread, but also offers a lot of primitives (called operators) to build an asynchronous processing pipeline (an asynchronous sequence). Some of these operators allow you to control where the execution happens.

In Reactor an operator from a given sequence never blocks the thread in which it executes, because that thread could be involved in another separate sequence. Therefore it is important for operators that execute user code that said user code doesn't block either (or else it could block more than the associated sequence).

Additionally, there's a network IO-oriented project called reactor-netty. As the name implies, it brings a reactive API on top of the famous non-blocking network IO library Netty, which uses yet another approached compared to Jetty continuations (from what I understand of these), but the end goal is the same (don't do 1 thread per request, avoid threads that just wait for IO to finish).

Have a look at the reference documentation and the learn page for learning material.