Blocking I/O operation with WebFlux

Question

We have a flow which we would like to implement with Reactive programming using Spring Boot 2 WebFlux. Currently we have no experience with Reactive programming.
As part of this flow we are going to create on or more HTTP requests (I guess using WebClient) and also read some data from DB.
We are considering to use AWS DynamoDB but as far as I understand the Java SDK does not support reactive API.
This read will be a blocking I/O operation, my question is whether there is a benefit for implementing part of this flow with WebFlux? More generally, does a single blocking I/O operation in the flow eliminates all the benefit that we get from implementing with reactive programming?

Wrangler

Answer 1

Based on your question reactive is the idle way to deal with blocking operation especially IO (network, file and etc...)

you can use a library that implements this api in a reactive way or wrap a blocking request with a reactive api, this usually done by placing the blocking op on anther thread pool

in spring webflux you can achieve something similar like

@GetMapping
public Mono<Response> getResponse() {
  return Mono.fromCallable(() -> blockingOp())
    .publishOn(Schedulers.elastic());        
}

publishOn in that case will cause all this flow to happen on another thread, you can choose dedicated thread pool as your choice

from the docs, elastic is a

Scheduler that dynamically creates ExecutorService-based Workers and caches the thread pools, reusing them once the Workers have been shut down.

Steinway

Answer 2

The following may not answer your question fully, but might be a little helpful. There is a question mentioned in the FAQ for the Spring Framework 5, which is,

What if there is no reactive library for my database?

The answer to this is:

One suggestion for handling a mix of blocking and non-blocking code would be to use the power of a microservice boundary to separate the blocking backend datastore code from the non blocking front-end API. Alternatively, you may also go with a worker thread pool for blocking operations, keeping the main event loop non-blocking that way.

I think someone from Pivotal might be the right person to give more insights on this.

Wahhabi

Thanks for the answer. But moving the blocking I/O operation to another service wouldn't cause a bottleneck in the other service? – Wrangler

Putting the blocking code with the non- blocking code, will always create a bottleneck. While on the other hand, if you have the blocking service separated, it will only create a bottleneck when its invoked from the non blocking service. That's what I think. – Wahhabi

I see, but for each request we are going to call the other service in order to fetch data from the DB. So this service Thread Pool is going to be exhusted pretty fast. – Wrangler