Blocking I/O operation with WebFlux

user_4770988 0
Viewed 3457

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?

spring-webflux spring-boot reactive-programming nonblocking java
2 Answers

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.

user_52353920

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.

user_38117630
Related