Reactive Programming vs Thread Based Programming

Question

I am new to this concept and want to have a great understanding of this topic. To make my point clear I want to take an analogy.

Let's take a scenario of Node JS which is single-threaded and provide fast IO operation using an event loop. Now that makes sense since It is single-threaded and is not blocked for any task.

While studying reactive programming in Java using reactor. I came to a situation where the main thread is blocked when an object subscribes and some delay event took place. Then I came to know the concept of subscribeOn.boundedElastic and many more pipelines like this.

I got it that they are trying to make it asynchronous by moving those subscribers to other threads.

But if it occurs like this then why is the asynchronous. Is it not thread-based programming? If we are trying to achieve the async behaviour of Node JS then according to my view it should be in a single thread.

Summary of my question is:

So I don't get the fact of using or calling reactive programming as asynchronous or functional programming because of two reason

1. Main thread is blocked
2. We can manage the thread and can run it in another pool. Runnable service/ callable we can also define.

Answer 1

First of all you can't compare asynchronous with functional programming. Its like comparing a rock with a banana. Its two separate things.

Functional programming is compared to other types of programming, like object oriented programming or procedural programming etc. etc.

Reactor is a java library, and java is an object oriented programming language with functional features.

Asynchronous i will explain with what wikipedia says

Asynchrony, in computer programming, refers to the occurrence of events independent of the main program flow and ways to deal with such events.

So basically how to handle stuff "around" your application, that is not a part of the main flow of your program.

In comparison to Blocking, wikipedia again:

A process that is blocked is one that is waiting for some event, such as a resource becoming available or the completion of an I/O operation.

A traditional servlet application works by assigning one thread per request.

So every time a request comes in, a thread is spawned, and this thread follows along the request until the request returns. If there is something blocking during this request, for instance reading a file from the operating system, or making a request to another service. The assigned thread will block and wait until the reading of the file is completed, or the request has returned etc.

Reactive works with subscribers and producers and makes heavy use of the observer pattern. Which means that as soon as some thing blocks, reactor can take that thread and use it for something else. And then it is un-blocked any thread can pick up where it left off. This makes sure that every thread is always in use, and utilized at 100%.

All things processed in reactor is done by the event loop the event loop is a single threaded loop that just processes events as quick as possible. Schedulers schedule things to be processed on the event loop, and after they are processed a scheduler picks up the result and carries on.

If you just run reactor you get a default scheduler that will schedule things for you completely automatically.

But lets say you have something blocking. Well then you will stop the event loop. And everything needs to wait for that thing to finish.

When you run a fully reactive application you usually get one event loop per core during startup. Which means lets say you have 4 cores, you get 4 event loops and you block one, then during that period of blockages your application runs 25% slower.

25% slower is a lot!

Well sometimes you have something that is blocking that you can't avoid. For instance an old database that doesn't have a non-blocking driver. Or you need to read files from the operating system in a blocking manor. How do you do then?

Well the reactor team built in a fallback, so that if you use onSubscribe in combination with its own elastic thread pool, then you will get the old servlet behaviour back for that single subscriber to a specific say endpoint etc.

This makes sure that you can run fully reactive stuff side by side with old legacy blocking things. So that maybe some reaquests usese the old servlet behaviour, while other requests are fully non-blocking.

You question is not very clear so i am giving you a very unclear answer. I suggest you read the reactor documentation and try out all their examples, as most of this information comes from there.