Blockieren des Endpunkts mit Blockieren anderer Endpunkte auf derselben Ressource ⇐ Java

[Anonymous]

Ich stoße auf unerwartetes Blockierungsverhalten in einer Quarkus-Anwendung, die RESTEasy Reactive und virtuelle Threads verwendet. Ich habe diese nur eingeworfen, um zu sehen, ob sie helfen würden, aber das haben sie nicht getan. Ich habe eine Ressource mit zwei @POST-Endpunkten, die beide mit @RunOnVirtualThread und @Blocking annotiert sind (um zu sehen, ob das Problem dadurch behoben wird, aber das ist nicht der Fall.)
Der Anwendungscode ist wie folgt strukturiert:

Code: Select all

// Endpoint 1: Simulates a long-running, blocking task
@POST
@Path("/{deviceId}/test")
@RunOnVirtualThread
@Blocking
public RestResponse testDevice(String deviceId) 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(String deviceId) throws InterruptedException {
log.info("Request received for quick operation.");
// This method returns almost immediately
return RestResponse.noContent();
}

Das Problem
Wenn ich eine Anfrage von einem ReactJS-Client an den Endpunkt mit langer Laufzeit initiiere (

Code: Select all

.../{deviceId}/test

), geht es korrekterweise für die erwarteten 20 Sekunden in den Status „Ausstehend“ über.
Während die erste Anfrage jedoch noch verarbeitet wird, sende ich sofort eine zweite Anfrage an den Schnellendpunkt (

Code: Select all

.../{deviceId}/test-other

) für das dasselbe Gerät, geht die zweite Anfrage ebenfalls in den Status PENDING über und wird erst gelöst, wenn die erste, lang laufende Anfrage abgeschlossen ist. Aber wenn ich diesen Endpunkt zum Beispiel mit Postman und nicht mit demselben Client anfordere, scheint alles zu funktionieren.
Die Protokolle zeigen an, dass der derselbe Thread (und deshalb vermute ich, derselbe Thread) beide Anfragen nacheinander für eine bestimmte Geräte-ID verarbeitet:
Meine Frage

• Warum wird die zweite Anfrage von der ersten blockiert?
• Welcher Mechanismus in RESTEasy Reactive/Quarkus verursacht die Serialisierung von Anforderungen für diese Ressource oder dieses Gerät?
• Wie kann ich diese Ressource/diese Endpunkte so konfigurieren, dass die zweite, schnelle Anforderung sofort ausgeführt werden kann, ohne auf den Abschluss der ersten warten zu müssen?
• Ich habe versucht, die Annotation @Blocking zu entfernen (die keine Auswirkung hatte) und habe sichergestellt, dass beide verwendet werden @RunOnVirtualThread. Welche spezifische Anmerkung oder Konfiguration ist erforderlich, um dieses endpunktübergreifende Blockierungsverhalten zu verhindern?