(I asked this question on StackOverflow, and it contais code I ommited here, but I think it would be suitable to ask it here aswell, since it's a network issue I'm facing)
I have an API (WebAPI) with SignalR hosted on an IIS 7.5 at a Windows Server 2008 R2 (production environment) and I connect to my hub through a desktop application running on Windows 10.
I'm experiencing an issue when establishing a connection with LongPollingTransport (I explicitly use it due to the server's configuration - WebSockets don't work on Windows Server 2008 R2 as far as I know): At first, the clients successfully connects and the connection is successfully received at SignalR's Hub.
But then, the client apparently disconnects, however the client doesn't catch any disconnection event as described above, it keeps "connected" even thought I know it's not when I call an API endpoint that indeed should send data to my client.
This issue happens only on that production environment, but I also tested in both my Local/Development environment (Windows 10) and Test environment (Windows Server 2012) and it works fine. With the logs enabled, I could see that, in the production environment, this "is dead" message by TransportHeartBeat happens:
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)
Meanwhile, in Local or Test environments, the log shows a "KeepAlive" message (which I would like it happened in my production environment):
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)
Also in my client application I have a method to send data to the server. When diagnosing with Fiddle, I noticed that in my Local or Test environments, the long pooling connection started by the client is kept alive until the client sends some data, then the connection finishes with no data by the server and another one starts. Meanwhile, in my test environment, the long pooling connection keeps going even if my client sends data. I think this happens because the server doesn't identity the client connection in the first place, but I thought it would be useful to mention that behaviour.
So, with all that said, I would like to know:
- Is there anything I should configure on IIS to make LongPoolingTransport work?
- Any idea of why my client "thinks" it's still connected?
- What could cause a long pooling request to be dropped like that? How can I diagnose that?
Thanks!
