0

We have a Spring Webflux based application, which returns a flux response. The application itself makes blocking calls to downstream services, and essentially acts as an aggregator. Each downstream request is a blocking HTTP POST request, and can take a variable amount of time (in the order of several seconds).

The current pattern we follow is to have the following:

Mono.fromCallable(() -> {

//client code for the blocking call

}).subscribeOn(Schedulers.boundedElastic()).flux()

If we have a large number of incoming connections this essentially means that we keep creating a lot of threads for these connections, and each thread is blocked on waiting for the response.

Would it better to use a AsyncHTTPClient instead, which would use NIO to issue non-blocking requests from within regular operations. Can anyone give an example for how this would work, and what are possible advantages/disadvantages to this approach?

tsar2512
  • 2,826
  • 3
  • 33
  • 61
  • 2
    The obvious choice is using Spring WebClient for this purpose which also uses NIO and provides its outcome as Mono/Flux. – Martin Tarjányi Feb 23 '20 at 10:04
  • @MartinTarjányi - Interesting thanks for the pointer could you give an example. Does WebClient work for only making calls to reactive applications which return a flux/mono response, or does it work for standard http api's. – tsar2512 Feb 23 '20 at 17:19
  • yes, it works with standard http apis, as well https://docs.spring.io/spring-boot/docs/2.2.4.RELEASE/reference/html/spring-boot-features.html#boot-features-webclient – Martin Tarjányi Feb 23 '20 at 18:08
  • Please Before asking more about webclient, read up on the official documentation for webclient. If they are unclear then you can ask questions – Toerktumlare Feb 23 '20 at 22:43

0 Answers0