BlockHound определяет метод WebClient ExchangeFunction .next () как блокирующий

Я профилирую свое приложение-реактор, используя 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 не помогает.


person Prashant Pandey    schedule 23.06.2020    source источник
comment
Какую трассировку стека показывает BlockHound?   -  person Phil Clay    schedule 23.06.2020


Ответы (1)


Согласно вашей сути, BlockHound обнаруживает java.io.FileInputStream.readBytes(..) как блокировку в глубине рукопожатия SSL.

Об этой проблеме сообщалось в https://github.com/reactor/reactor-netty/issues/939 и, похоже, решены в последних выпусках.

person Phil Clay    schedule 24.06.2020