SignalR Invoke cesse de fonctionner après la reconnexion

Question

Je me connecte à mon concentrateur SignalR via un client .Net, et l'appel d'une fonction sur le serveur fonctionne correctement jusqu'à ce que la connexion à IIS soit interrompue. Une fois la connexion restaurée automatiquement, l'invocation ne fonctionne plus.

J'ai vérifié dans la connexion de l'application Web que le client .Net se reconnectait avec succès et que l'état de connexion du client revenait à Connecté. Mais l'appel Invoke ne fait rien. En outre, si j'appelle Wait() sur l'appel, il se bloque pour toujours.

code:

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

Toutes les idées? Je dois noter que cela ne se produit pas lorsque le client s'exécute localement et se connecte à localhost; Cela ne se produit que lors de la reconnexion à un serveur différent.

Answer 1

Je rencontre le même problème, et j'ai vérifié avec le requin de fil, mais il n'y a aucun trafic sortant de mon hub à mon client. L'autre sens de la communication coule correctement!

Jusqu'à présent, je n'ai pas été en mesure d'établir une solution, mais je vous tiendrai au courant, je voulais juste partager mes conclusions.

Le suivi a été ajouté au concentrateur et au client et a constaté que le concentrateur fermait la connexion, mais pas le client. Depuis le logfile Hub:

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

Et dans l'exploitation forestière sur le client, il continue d'utiliser la même connexion

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

Hover Il y avait des messages réguliers du type suivant, qui ne sont plus envoyé.

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= ... 

cette page Signal R on the wire j'ai appris que le { "I": "232"} message signifie que: Un serveur méthode vide a été complété avec succès.

Ce qui est correct, car je peux voir les mises à jour car elles sont traitées dans le concentrateur. Mais quand j'appelle une méthode sur ce même ID de connexion, rien ne se passe. Et ce n'est pas étrange car le Hub a jugé que cette connexion était morte! Pourquoi la connexion est-elle morte sur le concentrateur pour les messages sortants, mais le concentrateur peut-il encore traiter les messages entrants de cette connexion?

résultats supplémentaires: Here il est mentionné que « côté client garder contrôle en vie ne soit pas utilisé pour le long transport de vote » et je l'ai trouvé une référence here que c'est en effet désactivé par défaut et le dernier commentaire sur cette question est "... cesse de recevoir la communication venant du serveur ..."

Si je comprends bien, nous permettons au client de rester en vie en réglant: GlobalHost.Configuration.KeepAlive Et nous avons réglé ceci, alors pourquoi le client ne détecte pas la mort de connexion!

Answer 2

Pas vraiment la meilleure solution, mais j'ai fini par juste réinitialiser la connexion lorsque l'état passe à "Reconnexion". Garbage Collection prendra soin de la connexion d'origine.

Espérons que ce problème sera éventuellement résolu.