WebClient hanging when using share() followed by block() call but calling block() only returns with an error

Question

I am using the Spring WebFlux WebClient in a spring batch application and I am getting an error when I call block. The code is really simple but I am getting an error when the application I try launching a job from a Rest endpoint on a controller in the batch job.

The rest endpoint is like this:

@RequestMapping("/migration/products/catalog 
class ProductController{
    private final Job job; 
    ResponseEntity<Map<String,Object> loadProductCatalog(){
       // Code  to launch Product Catalog Job
    }
}

Here is the method the calls a remote client to get Product Catalog information that can be used by the Controller to load information about products

 public ProductInfo findProductInfo()  {
    try{
        String url =....;
        return webClient.get().uri(url)
                .accept(MediaType.APPLICATION_JSON).retrieve().
                bodyToMono(ProductInfo.class).share().block();
    }catch(Exception e){
        log.error("Exception during retrieval of ProductInfo Data [}", e);
        return null;
    }

}

The findProductInfo method is wrapped in a Service which is used to retrieve ProductInfo in the Controller. I am using share() because the block() call to the Rest controller just hangs.

However, if I simply call block() with first calling share() the call to the controller returns but throws the following error. I'm very new to using WebFlux so I have no idea what is going on. I'd appreciate some help in deciphering what is going on and a solution to this problem

java.lang.IllegalStateException: block()/blockFirst()/blockLast() are blocking, which is not supported in thread reactor-http-nio-2

When I use share() followed by block() my application hangs when I invoke the rest endpoint. However, if I use block() alone the method returns

Answer 1

Solved: My job was running in a single thread, so the share().block() was blocking the main thread of the job launcher. I figured out that from observing the task executor was synchronous and that gave me the clue, it suddenly made sense. I configured a task executor so the job would run in its own thread and viola!