SignalR Invoke funktioniert nach Reconnect nicht mehr

Question

Ich verbinde mich über einen .Net-Client mit meinem SignalR-Hub, und das Aufrufen einer Funktion auf dem Server funktioniert einwandfrei, bis die Verbindung durch das Zurücksetzen von IIS verloren geht. Sobald die Verbindung automatisch wiederhergestellt wurde, funktioniert Invoke nicht mehr.

Ich habe in der Protokollierung der Web-App verifiziert, dass der .Net-Client die Verbindung erfolgreich wieder herstellt, und der Verbindungsstatus des Clients wechselt wieder zu Connected. Aber der Invoke-Aufruf macht nichts. Wenn ich Wait() für den Aufruf aufrufen, bleibt es außerdem für immer hängen.

Code:

//Works fine before connection lost, but hangs after connection restored 
myProxy.Invoke("MyServerFunction", param1).Wait(); 

Irgendwelche Ideen? Ich sollte beachten, dass dies nicht passiert, wenn der Client lokal ausgeführt wird und eine Verbindung zu localhost herstellt; Es passiert nur, wenn Sie sich erneut mit einem anderen Server verbinden.

Answer 1

Ich habe das gleiche Problem, und habe mit Drahthai überprüft, aber es gibt keinen ausgehenden Verkehr von meinem Hub zu meinem Client. Umgekehrt fließt die Kommunikation korrekt!

Bisher konnte ich keine Lösung finden, werde Sie aber auf dem Laufenden halten, wollte nur meine Erkenntnisse teilen.

Tracing zum Hub und zum Client hinzugefügt und festgestellt, dass der Hub die Verbindung schließt, der Client jedoch nicht. Vom Hub Logfile:

SignalR.Transports.TransportHeartBeat Verbose: 0 : d1992c3d-fbec-43e6-9662-b3e94af39418 is dead 
    SignalR.Transports.TransportHeartBeat Information: 0 : Removing connection d1992c3d-fbec-43e6-9662-b3e94af39418 

Und in der Protokollierung auf dem Client es

02:34:36.3191340 - d1992c3d-fbec-43e6-9662-b3e94af39418 - OnMessage({"I":"232"}) 

Hover, dort zu sein regelmäßige Meldungen der folgenden Art, die nicht mehr zu sein verwendet mit der gleichen Verbindung hält geschickt.

02:34:35.2053710 - d1992c3d-fbec-43e6-9662-b3e94af39418 - LP: OnMessage({"C":"d-7D145E50-B,18|N,5|O,1","M":[]}) 
02:34:35.2073150 - d1992c3d-fbec-43e6-9662-b3e94af39418 - LP Poll: http://172.16.2.101:8074/signalr/poll?clientProtocol=1.4&transport=longPolling&connectionData= ... 

auf dieser Seite Signal R on the wire erfuhr ich, dass die { "I": "232"} Meldung bedeutet, dass: Eine Server-void-Methode erfolgreich abgeschlossen wurde.

Das ist richtig, wie ich die Updates sehen kann, wie sie im Hub verarbeitet werden. Aber wenn ich eine Methode für dieselbe Verbindungs-ID aufruft, passiert nichts. Und das ist nicht seltsam, da der Hub diese Verbindung für tot hielt!

Warum ist die Verbindung auf dem Hub für ausgehende Nachrichten inaktiv, aber der Hub kann immer noch eingehende Nachrichten von dieser Verbindung verarbeiten?

Weitere Ergebnisse: Here wird erwähnt, dass „Client-Seite am Leben erhalten wird überprüft, für den langen Polling Transport nicht in Anspruch genommen“ und ich fand einen Verweis here, dass dies in der Tat ist deaktiviert standardmäßig und der letzte Kommentar zu diesem Thema ist "... hört auf, Kommunikation vom Server zu empfangen ..."

Wenn ich richtig verstehe, aktivieren wir den Client am Leben, indem wir Folgendes setzen: Und wir haben dies eingestellt, also immer noch, warum der Client Verbindung Tod nicht erkennt!

Answer 2

Nicht wirklich die beste Lösung, aber am Ende habe ich nur die Verbindung neu initialisiert, wenn sich der Status in "Reconnecting" ändert. Hoffentlich kümmert sich Garbage Collection um die ursprüngliche Verbindung.

Hoffentlich wird dieses Problem schließlich behoben werden.