Длинный пул SignalR отключается в IIS 7.5 и Windows Server 2008 R2 без вывода сообщений
( Я задал этот вопрос на StackOverflow, и он содержит код, который я здесь пропустил, но я думаю, что было бы целесообразно задать его и здесь, так как это проблема сети, с которой я сталкиваюсь)
У меня есть API (WebAPI) с SignalR, размещенный на IIS 7.5 в Windows Server 2008 R2 (производственная среда), и я подключаюсь к своему концентратору через настольное приложение, работающее в Windows 10.
У меня возникает проблема при установлении соединения с LongPollingTransport (я явно использую его из-за конфигурации сервера - насколько я знаю, WebSockets не работает на Windows Server 2008 R2): Сначала клиенты успешно подключаются, и соединение успешно получен в Центре SignalR.
Но затем клиент явно отключается, однако клиент не перехватывает никакого события отключения, как описано выше, он сохраняет "подключение", даже если я знаю, что это не когда я вызываю конечную точку API, которая действительно должна отправлять данные моему клиенту.
Эта проблема возникает только в этой производственной среде, но я также провел тестирование в локальной среде / среде разработки (Windows 10) и тестовой среде (Windows Server 2012), и она отлично работает. С включенными журналами я мог видеть, что в производственной среде это "мертвое" сообщение от TransportHeartBeat происходит:
SignalR.Transports.TransportHeartBeat Information: 0 : Connection 96c15a60-dd1d-47fb-ac57-ea898712738f is New.
SignalR.Transports.LongPollingTransport Verbose: 0 : DrainWrites(96c15a60-dd1d-47fb-ac57-ea898712738f)
SignalR.Transports.LongPollingTransport Information: 0 : CompleteRequest (96c15a60-dd1d-47fb-ac57-ea898712738f)
SignalR.Transports.TransportHeartBeat Verbose: 0 : 96c15a60-dd1d-47fb-ac57-ea898712738f is dead
SignalR.Transports.TransportHeartBeat Verbose: 0 : 96c15a60-dd1d-47fb-ac57-ea898712738f is dead
SignalR.Transports.TransportHeartBeat Verbose: 0 : 96c15a60-dd1d-47fb-ac57-ea898712738f is dead
SignalR.Transports.TransportHeartBeat Verbose: 0 : 96c15a60-dd1d-47fb-ac57-ea898712738f is dead
SignalR.Transports.TransportHeartBeat Verbose: 0 : 96c15a60-dd1d-47fb-ac57-ea898712738f is dead
SignalR.Transports.TransportHeartBeat Verbose: 0 : 96c15a60-dd1d-47fb-ac57-ea898712738f is dead
SignalR.Transports.TransportHeartBeat Verbose: 0 : 96c15a60-dd1d-47fb-ac57-ea898712738f is dead
SignalR.Transports.TransportHeartBeat Information: 0 : Removing connection 96c15a60-dd1d-47fb-ac57-ea898712738f
SignalR.Transports.LongPollingTransport Information: 0 : Abort(96c15a60-dd1d-47fb-ac57-ea898712738f)
SignalR.Transports.LongPollingTransport Information: 0 : End(96c15a60-dd1d-47fb-ac57-ea898712738f)
Между тем, в локальной или тестовой средах в журнале отображается сообщение "KeepAlive" (что, как мне хотелось бы, происходило в моей производственной среде):
SignalR.Transports.TransportHeartBeat Information: 0 : Connection fb4c9f24-7359-4f84-80d4-622b8e4d2e8d is New.
SignalR.Transports.LongPollingTransport Verbose: 0 : DrainWrites(fb4c9f24-7359-4f84-80d4-622b8e4d2e8d)
SignalR.Transports.LongPollingTransport Information: 0 : CompleteRequest (fb4c9f24-7359-4f84-80d4-622b8e4d2e8d)
SignalR.Transports.TransportHeartBeat Verbose: 0 : Connection fb4c9f24-7359-4f84-80d4-622b8e4d2e8d exists. Closing previous connection.
SignalR.Transports.LongPollingTransport Information: 0 : End(fb4c9f24-7359-4f84-80d4-622b8e4d2e8d)
SignalR.Transports.LongPollingTransport Verbose: 0 : DrainWrites(fb4c9f24-7359-4f84-80d4-622b8e4d2e8d)
SignalR.Transports.LongPollingTransport Information: 0 : CompleteRequest (fb4c9f24-7359-4f84-80d4-622b8e4d2e8d)
SignalR.Transports.TransportHeartBeat Verbose: 0 : Connection fb4c9f24-7359-4f84-80d4-622b8e4d2e8d exists. Closing previous connection.
SignalR.Transports.LongPollingTransport Information: 0 : End(fb4c9f24-7359-4f84-80d4-622b8e4d2e8d)
SignalR.Transports.LongPollingTransport Verbose: 0 : DrainWrites(fb4c9f24-7359-4f84-80d4-622b8e4d2e8d)
SignalR.Transports.LongPollingTransport Information: 0 : CompleteRequest (fb4c9f24-7359-4f84-80d4-622b8e4d2e8d)
SignalR.Transports.TransportHeartBeat Verbose: 0 : Connection fb4c9f24-7359-4f84-80d4-622b8e4d2e8d exists. Closing previous connection.
SignalR.Transports.LongPollingTransport Information: 0 : End(fb4c9f24-7359-4f84-80d4-622b8e4d2e8d)
SignalR.Transports.TransportHeartBeat Verbose: 0 : KeepAlive(fb4c9f24-7359-4f84-80d4-622b8e4d2e8d)
SignalR.Transports.TransportHeartBeat Verbose: 0 : KeepAlive(fb4c9f24-7359-4f84-80d4-622b8e4d2e8d)
SignalR.Transports.TransportHeartBeat Verbose: 0 : KeepAlive(fb4c9f24-7359-4f84-80d4-622b8e4d2e8d)
SignalR.Transports.TransportHeartBeat Verbose: 0 : KeepAlive(fb4c9f24-7359-4f84-80d4-622b8e4d2e8d)
SignalR.Transports.TransportHeartBeat Verbose: 0 : KeepAlive(fb4c9f24-7359-4f84-80d4-622b8e4d2e8d)
Также в моем клиентском приложении у меня есть метод для отправки данных на сервер. При диагностике с помощью Fiddle я заметил, что в моей локальной или тестовой средах соединение с длинным пулом, запущенное клиентом, сохраняется, пока клиент не отправит некоторые данные, затем соединение завершается без данных сервером и запускается другое. Между тем, в моей тестовой среде соединение с длинным пулом продолжает работать, даже если мой клиент отправляет данные. Я думаю, что это происходит потому, что сервер не идентифицирует клиентское соединение, но я подумал, что было бы полезно упомянуть такое поведение.
Итак, со всем, что сказал, я хотел бы знать:
- Что-нибудь, что я должен настроить на IIS, чтобы заставить LongPoolingTransport работать?
- Есть идеи, почему мой клиент "думает", что он все еще подключен?
- Что может привести к тому, что длинный запрос на объединение будет отброшен таким образом? Как я могу диагностировать это?
Спасибо!