У меня есть некоторые конечные точки REST, реализованные в микроавтобусе (сервис A). Одна из конечных точек вызывает другую службу (службу X), используя java.net.http.HttpRequest
. Сервис X может иметь большое время отклика, например, минуты. Как только этот вызов выполняется, я регулярно звоню в службу A (из curl), и время от времени он просто зависает.
Я проверял звоню в мой сервис А с завитком. Для меня это выглядит так, как только служба A находится в обращении к службе X, она удерживает один из потоков nioEventLoopGroup-1-x
, ожидающих завершения операции блокировки sh. Последующие вызовы в службу A конечные точки будут обрабатываться различными потоками nioEventLoopGroup-1-#
циклически. Но как только у блокировки nioEventLoopGroup-1-x
наступит очередь, запрос просто зависнет. Это поведение является детерминированным c. Из журналов видно, какой поток nio обрабатывает запрос. Я вижу, что когда заблокированный поток получает очередь, вызов службы A просто зависает. Затем я делаю новый запрос к сервису А, который ответит отлично. Если размер пула потоков нетто 5 и 1 поток обработчика нетто заблокирован, то у меня будет каждый 5-й запрос на обслуживание зависания.
По моему мнению, Micronaut никогда не должен пытаться назначить обработку запроса http для поток, который заблокирован, но, видимо, это происходит.
Кто-нибудь есть какие-либо предложения, как преодолеть эту проблему?