SockJS -> Infinite XHR-Streaming-Anrufe nach dem Wiederverbinden

Question

im mit Stomp über SockJS und Feder Websockets als Backend. Gelegentlich habe ich Probleme nach meinem Stomp-Client wiederverbinden (WLAN-Verlust, Server-down, andere). Die Verbindung ist perfekt wiederhergestellt, aber einige Sekunden kann ich im Browser-Netzwerk sehen, wie SockJS-Client versuchen und versuchen, xhr-Streaming mit der alten Session-ID zu senden. Die Backend-Antwort mit Closed Frame c [1000, "Go Away!"] Die Anwendung funktioniert noch, aber dieses Problem lädt die CPU und verlangsamt die Anwendung.

Ich konnte ausschalten und den Server mehrmals starten (nicht immer passieren). Ich kann nicht verstehen, wie SockJS einmal wiederverbunden (Wir zerstören und erstellen Sie die Sockjs-Instanz von 0) senden xhr-Streaming-Anfragen mit der ID der alten Sitzung (Behält die Pre-Reconnection ID Sitzung? Speicherleck?). Ich möchte es Socks nach der Wiederverbindung nicht irgendeinen Zustand behalten und immer von vorne anfangen.

Backend-Log:

2016-05-02 21:45:01.943 DEBUG [http-nio-8090-exec-7] o.s.w.s.s.t.h.XhrStreamingTransportHandler - Connection already closed (but not removed yet) for XhrStreamingSockJsSession[id=ypsjtids] 

Client-Protokoll:

(New Sitzungs-ID -> h2pystok, Alte Session-ID -> ypsjtids)

<<< PONG 
browser.js:120 sockjs-client:buffered-sender send +45ms "\n" 
browser.js:120 sockjs-client:buffered-sender sendSchedule +0ms 1 
browser.js:120 sockjs-client:ajax-based create ajax sender +2ms  http://localhost/eess-services/stomp/355/h2pystok ["\n"] 
browser.js:120 sockjs-client:browser:xhr POST +0ms http://localhost/eess-services/stomp/355/h2pystok/xhr_send 
ws.js:216 >>> PING 
browser.js:120 sockjs-client:browser:xhr withCredentials +2ms 
browser.js:120 sockjs-client:browser:xhr readyState +18ms 4 
browser.js:120 sockjs-client:browser:xhr status +1ms 200 
browser.js:120 sockjs-client:browser:xhr finish +0ms 200 hhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh 
o 
h 
h 
h 
h 
h 

browser.js:120 sockjs-client:receiver:xhr finish +0ms 200 hhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh 

browser.js:120 sockjs-client:receiver:xhr _chunkHandler +0ms 200 
browser.js:120 sockjs-client:receiver:xhr close +0ms network 
browser.js:120 sockjs-client:polling close +1ms null network undefined 
browser.js:120 sockjs-client:polling _scheduleReceiver +0ms 
browser.js:120 sockjs-client:receiver:xhr http://localhost/eess- services/stomp/266/ypsjtids/xhr_streaming +0ms 
browser.js:120 sockjs-client:browser:xhr POST +1ms http://localhost/eess-services/stomp/266/ypsjtids/xhr_streaming 

Es gibt ein Problem in GitHub: https://github.com/sockjs/sockjs-client/issues/308

Ich habe dieses Problem in der Produktion :( Grüße.

EDIT:

Ich fand, wo der mögliche Fehler ist. In polling.js habe ich eine spezielle Behandlung gesehen, wenn der nahe Grund "Netzwerk" ist. Wann ist Netzwerk wieder die Funktion _scheduleReceiver() aufrufen. Wenn wir die Verbindung wieder herstellen, tritt die Endlosschleife auf. Ich weiß nicht, was der Grund für diese Behandlung ist, aber ich könnte versuchen, dies die spezielle Behandlung von "Netzwerk" zu löschen und alles funktioniert richtig. @skozin Können Sie es versuchen?

if (! Self.pollIsClosing) {if (Grund === 'Netzwerk') {self._scheduleReceiver(); } else {self.emit ('close', code || 1006, Grund); self.removeAllListeners(); }}

die Abhilfe ist:

if (! Self.pollIsClosing) {self.emit ('close', Code || 1006, Grund); self.removeAllListeners(); }

Answer 1

Ich hatte das gleiche Problem. Meine App lief auf dem sicheren "https: //", wo ich versuche, die Datei sockjs-0.3.min.js von einem "ungesicherten CDN-Ort" zu holen, die die .js-Datei nicht herunterladen kann. Das bewirkt, dass Xhr_Streaming anstelle meiner Socks-Methoden beim Trennen des Sockets sucht. Einige Referenzen in Bezug auf http vs https: https://developers.google.com/web/fundamentals/security/prevent-mixed-content/fixing-mixed-content

ich dieses Problem behoben, indem die "ungesicherte CDN Weg zum gesicherten CDN Weg" Ändern dh

"< script src =" https: //cdn.jsdelivr .net/sockjs/0.3.4/sockjs.min.js "> </script>"