Überprüfen Sie die Client-Konnektivität zu einem RESTful Spring-Server, ohne die Antwort der Anwendung zu ändern ⇐ Java

[Guest]

Ich habe einen REST-Dienst in Spring und eine API, die für einige blockiert, bevor eine schwere Aufgabe gestartet und dann an den Client zurückgegeben wird. Ich möchte überprüfen, ob der Client noch mit dem Socket der Anfrage verbunden ist, bevor ich mit der schweren Aufgabe beginne, damit ich keine Rechenleistung an jemanden verschwende, der die Verbindung bereits getrennt hat. Ich kann keinen WebSocket verwenden und bin mir bewusst, dass die einzige Möglichkeit, zu überprüfen, ob die TCP-Verbindung noch offen ist, darin besteht, einige Daten darauf zu schreiben. Allerdings folgt meine HTTP-Antwort einem strikten Format und das Schreiben von irgendetwas darauf würde dieses Format durcheinander bringen.
Ich habe einen alten Tomcat-Thread aus dem Jahr 2009 gefunden, der besagt, dass wir dies erreichen können, indem wir leere Bytes leeren (

Code: Select all

new byte[0]

) an Response.getOutputStream, aber als ich es versuchte, erhielt ich keine Ausnahme, selbst wenn der Client die Verbindung geschlossen hatte. Ich habe den Quellcode von Tomcat durchgesehen und festgestellt, dass Flushes übersprungen werden, deren Länge nicht > 0 ist. Daher glaube ich nicht, dass diese Lösung funktioniert.
Ich denke, dass ich bräuchte etwas auf der TCP-Ebene, etwa einen PING oder Keep-Alive, aber ich konnte keine Ressourcen dafür finden, wie ich das für meinen Anwendungsfall machen könnte. Die Integration von Spring für TCP scheint neue Verbindungen mit einem konfigurierten Server herzustellen, anstatt den Socket der eingehenden Anforderungen zu verwenden. Die Keep-Alive-Konfigurationen von Tomcat scheinen für die Zeitüberschreitung von Anfragen zu dienen und nicht für die Überprüfung, ob der Benutzer die Verbindung getrennt hat (ich möchte keine Zeitüberschreitung bei der Verbindung zu meinem Server erzielen).
Idealerweise Ich möchte die Konnektivität regelmäßig überprüfen, damit ich die Ressourcen früher entsperren und freigeben oder die schwere Aufgabe anhalten kann, wenn der Client nach dem Start der Aufgabe die Verbindung trennt. Aber wenn das zu schwierig ist, dann ist es auch in Ordnung, die Konnektivität kurz vor Beginn der schweren Aufgabe einmal zu überprüfen.
Bearbeiten:
@talex wies im Kommentar darauf hin, dass es unmöglich ist, den von mir vorgeschlagenen TCP-Heartbeat-Typ zu erreichen, ohne das Protokoll zu ändern. Jetzt denke ich über eine weniger robuste Prüfung nach, bei der wir prüfen, ob wir ein FIN-Paket vom Client erhalten haben, und nicht Fälle bearbeiten, in denen der Client die Verbindung abrupt trennt. Wäre dies in der Spring-Architektur umsetzbar? Ich habe eine verwandte SO-Frage gefunden, aber ihre Lösung besteht darin, den EOF zu erkennen, was in meinem Fall immer zutrifft, da Spring den Stream für mich analysiert hätte, wenn ich meinen Controller erreiche.