Quarkus/RESTEasy Reactive: блокировка конечной точки с блокировкой других конечных точек на том же ресурсе ⇐ JAVA

[Anonymous]

Я столкнулся с неожиданным поведением блокировки в приложении Quarkus, использующем RESTEasy Reactive и виртуальные потоки. Просто добавил их, чтобы посмотреть, помогут ли они, но они не помогли. У меня есть ресурс с двумя конечными точками @POST, обе с аннотациями @RunOnVirtualThread и @Blocking (чтобы посмотреть, решит ли это проблему, но это не помогло...)
Код приложения структурирован следующим образом:

Код: Выделить всё

String deviceId; // Assumed to be injected via a filter or standard mechanism

// Endpoint 1: Simulates a long-running, blocking task
@POST
@Path("/{deviceId}/test")
@RunOnVirtualThread
@Blocking
public RestResponse testDevice() throws InterruptedException {
// deviceId is a placeholder for the path parameter or header injection
log.info("Testing digital signage device: {}", deviceId);
Thread.sleep(20_000); // 20-second simulated block
return RestResponse.noContent();
}

// Endpoint 2: A quick, non-blocking task
@POST
@Path("/{deviceId}/test-other")
public RestResponse testOtherDevice() throws InterruptedException {
log.info("Request received for quick operation.");
// This method returns almost immediately
return RestResponse.noContent();
}

Проблема
Когда я инициирую запрос от клиента ReactJS к долгоработающей конечной точке (

Код: Выделить всё

.../{deviceId}/test

), он правильно переходит в состояние ожидания на ожидаемые 20 секунд.
Однако, пока первый запрос все еще обрабатывается, если я немедленно отправлю второй запрос в быструю конечную точку (

Код: Выделить всё

.../{deviceId}/test-other

) для того же устройства, второй запрос также переходит в состояние PENDING и не обрабатывается до тех пор, пока не завершится первый, длительный запрос. Но если я запрашиваю эту конечную точку, например, с помощью Postman, а не с тем же клиентом - все, кажется, работает.
Журналы показывают, что один и тот же поток (и, следовательно, я подозреваю, один и тот же поток) последовательно обрабатывает оба запроса для данного идентификатора устройства:
Мой вопрос

• Почему второй запрос блокируется первым один??
• Какой механизм в RESTEasy Reactive/Quarkus вызывает сериализацию запросов к этому ресурсу или устройству?
• Как настроить этот ресурс/конечные точки, чтобы второй быстрый запрос выполнялся немедленно, не дожидаясь завершения первого?

Я попробовал удалить аннотацию @Blocking (безрезультатно) и убедился, что оба используют @RunOnVirtualThread. Какая конкретная аннотация или конфигурация необходима для предотвращения такого поведения блокировки между конечными точками?

Подробнее здесь: https://stackoverflow.com/questions/798 ... nts-on-the