Understanding the Reactive Thread Model: Part 1
Join the DZone community and get the full member experience.Join For Free
Reactive or non-blocking processing is in high demand, but before adopting it, one should deeply understand its thread model. For thread model two things are very important to know: thread communication and execution flow. In this blog, I will try to explain both of these topics in-depth.
What Is Reactive Programming?
There are lots of definitions on the web; the Wiki definition is a bit theoretical and generic. From a threading perspective, my version is "Reactive Programming is the processing of the asynchronous event stream, on which you can observe.”
You can find much more discussion about Reactive Programming on the web but for now, let’s stick to our topic of the Reactive Thread Model. Let’s start with a very simple reactive use case, where we want to return the sum of an integer array.
Our main request thread should not get blocked while processing the sum of an integer array. Let’s start by creating a simple WebServer.
Here, we are creating a socket server, opening a socket, and keeping the socket alive until the asynchronous processing is completed. Asynchronous processing is happening by calling the
nonBlockingSum method and passing the consumer function or lambda as an observable. Once the sum is ready, our function/lambda will get a callback. From the callback, we return the sum value to the client via a socket.
So, if you call the URL, http://localhost:9090 in parallel/sequence, you will get the following response:
The above is just used as an example. In the real world, you should use netty/undertow/servlet 3.1 as the reactive webserver. Now let’s get somewhat deep and try to understand the following flows:
- Blocking Call.
- Non-blocking call.
- Non-blocking call with thread execution.
- Serial business flow processing.
- Parallel business flow processing.
We are going to use Spring WebFlux, which is built on top of the Reactor framework for Reactive programming. Let’s cover sections 1 and 2 in this blog and other sections in part-2 so that it will be very easy to understand.
We are going to write a simple sum method and make it Reactive using the supplier function.
As shown in the diagram, the request thread is getting blocked until the computation of the sum is completed. If we execute the code, we will get the following response:
This clearly shows that the blocking call waited until the sum execution was completed.
Here, the request thread is not blocked, and the execution of the sum is shifted to a thread allocated from the thread pool. The callback and function/lambda are also executed on the same thread. If we execute, the code, we will get the following response:
This clearly shows that the request thread didn’t wait until the sum is computed. Also, the consumer and sum were processed in the same thread.
Published at DZone with permission of Milind Deobhankar. See the original article here.
Opinions expressed by DZone contributors are their own.