BlockHound 将 WebClient 的 ExchangeFunction 的 .next() 方法检测为阻塞答案

【问题标题】：BlockHound Detects WebClient's ExchangeFunction's .next() Method As BlockingBlockHound 将 WebClient 的 ExchangeFunction 的 .next() 方法检测为阻塞
【发布时间】：2020-10-13 10:00:23
【问题描述】：

我正在使用 BlockHound 分析我的反应器应用程序。我的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 在next.exchange() 上检测到阻塞调用。现在既然我使用WebClient 和Netty，为什么这个调用是非阻塞的？在elastic 线程上订阅它并没有帮助。

【问题讨论】：

BlockHound 显示的堆栈跟踪是什么？
@PhilClay gist.githubusercontent.com/pandepra/…

标签： reactive-programming project-reactor reactor reactor-netty

【解决方案1】：

根据您的要点，BlockHound 将 java.io.FileInputStream.readBytes(..) 检测为 SSL 握手中的深层阻塞。

此问题已在 https://github.com/reactor/reactor-netty/issues/939 中报告，并且似乎已在最新版本中得到解决。

【讨论】：