Graceful Behandlung von Server-Timeout in BlazeDS

Question

Ich habe einen Flex-Client, der Service-Anrufe an einen Tomcat-Server mit BlazeDS macht. Ich möchte in dieser Umgebung die Zeitlimits für die Server-Sitzung elegant behandeln.

Ich habe Sicherheitseinschränkungen für den Dienst, also authentifiziert sich der Client gegen ein entferntes Objekt, indem er ein ChannelSet basierend auf dem Ziel initialisiert und sich dann mit diesem ChannelSet anmeldet.

Nachdem der Benutzer authentifiziert ist, wenn sie eine (lange) Tasse Kaffee bekommen, wird ihre Sitzung unweigerlich Timeout.

Ich möchte, dass der Client das Zeitlimit erkennt und den Benutzer mit den entsprechenden Informationsnachrichten zurück auf die Anmeldeseite bringt.

Aber ich habe Schwierigkeiten, den besten Weg zu finden, diese Zeitüberschreitung vom Client zu erkennen. Ist es möglich, oder muss der Server einen Fehler ausgeben, wenn die Zeitüberschreitung auftritt?

Danke!

Answer 1

Sehen Sie in der Dokumentation nach, ob ein Ereignis ausgelöst wird, wenn die Verbindung getrennt wird. Ich könnte mir vorstellen, dass es da ist. Wenn nicht, verwenden Sie try/catch um Ihre Verbindungen und fangen Sie alle Verbindungsprobleme auf. Wenn Sie dies tun, leiten Sie Ihre App um und benachrichtigen Sie den Benutzer. Sie müssen wahrscheinlich damit spielen, um die genauen Fehlercodes zu finden, die für die Verbindungsprobleme geworfen werden, aber es sollte im Debugging ziemlich einfach sein.

Answer 2

Ich habe dieses Problem bei einem Projekt festgestellt, insbesondere weil BlazeDS ein anderes Sitzungszeitlimit als die eigentliche Anwendung hatte (mit einer Single-Sign-On-Architektur über ClearTrust). Beachten Sie, dass dies in einer JBoss-Umgebung erfolgte. Am Ende habe ich einen relativ einfachen Ansatz gewählt, indem ich nach zwei spezifischen faultCodes in den Fehlerbehandlern gesucht habe (hatte eine Basisklasse mit einem gemeinsamen Fehlerbehandler): DuplicateSessionDetected und DeliveryInDoubt. Ich habe die Meldung DuplicateSessionDetected gesehen, wenn BlazeDS versuchte, eine neue Sitzung für dieselbe JBoss-Sitzungs-ID zu erstellen. DeliveryInDoubt tendierte dazu, manchmal auch zu erscheinen, aber ich bin mir nicht sicher warum. Als ich diese Fehlercodes sah, habe ich dann die notwendigen Maßnahmen ergriffen, um die App zu aktualisieren (je nach Ihren Bedürfnissen könnten Sie auf eine Anmeldeseite oder etwas anderes umleiten). Offensichtlich müssen Sie je nach Umgebung auf einen anderen Fehlercode warten, und dieser Ansatz funktioniert möglicherweise nicht in jeder Situation mit unterschiedlichen Umgebungen/Konfigurationen/etc.

Ein anderer Ansatz, der diskutiert wurde, war die Verwendung eines Timers in der Flex App, der den BlazeDS Timeout-Timer darstellen würde, aber ich bin kein Fan von Timern, die zu diesem Zweck herumstehen. Ich habe auch gehört, dass ein kleiner Teil der Daten zum Server geschickt wurde, um nach einer Zeitüberschreitung zu suchen, aber das schien wiederum alles andere als ideal.

Answer 3

Wir haben eine benutzerdefinierte Komponente für den Client geschrieben, die Tastatureingaben und Mausereignisse erfasst und dann Timeouts auf dem Client verarbeitet.

Answer 4

Ich stieß auf dieses Problem in einem meiner Projekte. Was ich getan habe, um dies zu überwinden, ist jedes Mal, wenn der Client über RemoteObject oder HTTPService auf den Server zugreift, überprüft er zuerst die Authentifizierung des Benutzers, wenn es bereits abgelaufen ist, wird etwas zurückgegeben und wenn es in Ordnung ist, wird es weiterarbeiten. Im Response-Handler-Ergebnisereignis der Clientseite überprüft der Client, ob die Antwort eine Zeitüberschreitung aufweist, und wenn dies der Fall ist, wird er erneut zur Anmeldeseite weitergeleitet. Soweit ich weiß, gibt es keine Möglichkeit, dass der Server einen Fehler an den Client sendet, wenn die Sitzung des Benutzers abgelaufen ist. Sie werden nur wissen, dass die Sitzung beim nächsten Zugriff auf den Server abgelaufen ist.

Answer 5

Implementieren Sie die FlexSessionListener-Schnittstelle auf der Serverseite. Es bietet eine Möglichkeit, die Erstellung/Löschung von Flex-Sitzungen zu verarbeiten, bevor sie tatsächlich ausgeführt werden.

Verwenden Sie im SessionDestroyed-Handler einen Messaging-Producer, um eine Nachricht vom Server an den Client zu senden, die ihn darüber informiert, dass die Sitzung kurz vor dem Timeout steht.

Answer 6

Wir haben einen benutzerdefinierten UI-Dienst implementiert, der den Server ständig anpingt (1 Ping pro 10 Minuten) und somit verhindert, dass AppServer die Verbindung herunterfährt. Wir führen auch einen internen UI-Timer aus, der jedes Mal gelöscht wird, wenn eine Anfrage gestellt wird (mit Ausnahme von "ping"), mit einer vollständigen Funktion, die die Benutzeroberfläche aufruft, um zur Anmeldung zurückzukehren und "Sitzung abgelaufen wegen Client-Inaktivität" anzuzeigen.

Answer 7

Dies ist zu BlazeDS nicht spezifisch, sondern als von Flex 4.5 (möglicherweise früher) gibt es einen spezifischen Fehlercode auf dem Fehlerereignis für Timeout-Fehler:

In Ihren Fehler-Handler:

if(faultEvent.fault.faultCode == "Client.Error.RequestTimeout"){ 
    trace("TIMEOUT ERROR"); 
} 

Answer 8

Extend CallResponder, und überschreiben Sie die Fehlermethode.

Überprüfen Sie data.fault.faultCode auf bekannte Fehlercodes, z. B. ErrorMessage.MESSAGE_DELIVERY_IN_DOUBT.

Wenn Sie einen Treffer erhalten, verwenden Sie die native Funktion navigateToURL zum Umleiten.