SignalR Invoke перестает работать после Reconnect

Question

Я подключаюсь к своему концентратору SignalR через .Net-клиент и вызывая функцию на сервере, работает нормально до тех пор, пока соединение не будет потеряно при перезагрузке IIS. Как только соединение будет восстановлено автоматически, Invoke больше не будет работать.

В вебе веб-приложения проверено, что клиент .Net успешно переподключается, а состояние подключения клиента возвращается к подключенному. Но вызов Invoke ничего не делает. Кроме того, если я вызываю Wait() в вызове, он зависает вечно.

Код:

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

Любые идеи? Следует отметить, что этого не происходит, когда клиент работает локально и подключается к localhost; это происходит только при повторном подключении к другому серверу.

Answer 1

У меня такая же проблема, и я проверил проводную акулу, но от моего концентратора до моего клиента нет исходящего трафика. Поведение в обратном направлении идет правильно!

До сих пор я не мог установить решение, но будет держать вас в курсе, просто хотел поделиться своими выводами.

Добавлена ​​трассировка на концентратор и клиент и заметили, что концентратор закрывает соединение, но клиент этого не делает. Из логфайл 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 

И в протоколирования на клиенте продолжает использовать то же самое соединение

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

Hover там раньше были регулярные сообщения следующего типа, которые больше не является послал.

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

с этой страницы Signal R on the wire я узнал, что { «я»: «232»} сообщение означает, что: Пустота метод сервера был успешно завершен.

Что является правильным, поскольку я могу видеть обновления, поскольку они обрабатываются в концентраторе. Но когда я вызываю метод на том же идентификаторе соединения, ничего не происходит. И это не странно, поскольку Хаб считал, что связь мертва!

Итак, почему соединение отключено на концентраторе для исходящих сообщений, но концентратор все еще способен обрабатывать входящие сообщения из этого соединения?

Дополнительные данные: Here отмечается, что «на стороне клиента поддерживать проверка не используется в течение длительного избирательного транспорта», и я нашел ссылку here, что это действительно отключен по умолчанию и последний комментарий по этому вопросу «... перестает получать сообщения, поступающие с сервера ...»

Если я правильно понимаю, мы поддерживаем поддержку клиента, установив: GlobalHost.Configuration.KeepAlive И мы установили это, так почему же клиент не обнаруживает смерть соединения!

Answer 2

На самом деле это не лучшее решение, но в итоге я просто переинициализировал соединение, когда состояние изменилось на «Повторное подключение». Надеюсь, коллекция мусора позаботится об исходном соединении.

Надеюсь, эта проблема будет решена в конце концов.