Reactive API needs to call parallel downstream APIs and await responses

I have a number of devices (currently eight, but could be more in the future) with a simple blocking HTTP REST api. One makes a GET call to give a value, the API responds with success or fail, but always a 200. There’s another GET to find the current setting. So, a typical sequence would be:

http://\<some address\>/devicename/set/10

http://\<some address\>/devicename/get

I have a Spring Boot reactive API to call these downstream APIs in parallel that currently uses Mono.zip(). I only have the set() coded. When I call the reactive API, it works in that it makes all of the set() calls, and sends back a response to the reactive API caller showing the results.

The problem I have is: I need to programmatically await the results of all of the set() calls, do the get() calls, awaiting those responses, then optionally do more rounds of set() -> get() until the values all are either in compliance or the retries are exhausted.

I’ve tried a number of variations:

1. block() – errors at runtime with block()/blockFirst()/blockLast() are blocking, which is not supported in thread reactor-http-nio-3
2. CountDownLatch inside a subscribe() – never completes and doesn’t decrement the latch
3. subscribe() (several variations) – still doesn’t await all of the responses.

I feel like there’s something trivial I’m missing. Clearly, somewhere in the reactive API, the waiting is happening, because it always returns to the caller with all of the completed set() responses. Often, this will take 30 to 40 seconds for all to complete, which is expected and OK.

I need to be able to do that in the user code, and initiate the other calls as mentioned. I hit the reactive API with a browser, and honestly, even if the browser call times out, that’s OK, as long as the work gets done. I do need to retain the parallel calls to the downstream in all cases, as each device can be doing the work at the same time.

Ideas?

Brad

You need to sign in to view this answers