BlockHound Detects WebClient's ExchangeFunction's .next() Method As Blocking

Question

I am profiling my reactor application using BlockHound. I have a filter on my ExchangeFunction:

@Override
public Mono<ClientResponse> filter(ClientRequest request, ExchangeFunction next) {
final ClientRequest.Builder builder = ClientRequest.from(request);
return Mono.defer(() -> next.exchange(builder.build())) //detects blocking call
    .transform(reactiveUtil::contextualize)
    .publishOn(Schedulers.parallel());
}

BlockHound detects a blocking call on the next.exchange(). Now since I am using WebClient with Netty, why would this call be non-blocking? Subscribing this on an elastic thread does not help.

Answer 1

According to your gist, BlockHound is detecting java.io.FileInputStream.readBytes(..) as blocking deep within the SSL handshake.

This problem has been reported in https://github.com/reactor/reactor-netty/issues/939 and appears to be resolved in the latest releases.