1

I'm connecting to my SignalR hub via a .Net Client, and invoking a function on the server works fine until the connection is lost from resetting IIS. Once the connection is restored automatically, the Invoke no longer works.

I verified in the web app's logging that the .Net client is successfully reconnecting, and the client's connection state is changing back to Connected. But the Invoke call isn't doing anything. Additionally, if I call Wait() on the invoke, it hangs forever.

Code:

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

Any ideas? I should note that this doesn't happen when the client is running locally and connecting to localhost; it only happens when reconnecting to a different server.

Andrew Gale
  • 101
  • 1
  • 4

2 Answers2

1

I am experiencing the same issue, and have checked with wire shark, but there is no outgoing traffic from my hub to my client. The other way around the communication is flowing correctly!

So far I have not been able to establish a solution, but will keep you posted, just wanted to share my findings.

Added tracing to the hub, and the client and noticed that the hub closes the connection, but the client does not. From the 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

And in the logging on the client it keeps using the same connection

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

Hover there used to be regular messages of the following type, which are no longer being sent.

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

from this page Signal R on the wire I learned that the {"I":"232"} message means that:A server void method was completed successfully.

Which is correct, as I can see the updates as they are processed in the hub. But when I invoke a method on that same connection ID nothing happens. And that is not strange as the Hub deemed that connection to be dead!

So why is the connection dead on the hub for outgoing messages, but the hub still able to process incomming messages from that connection?

Additional findings: Here it is mentioned that "client side keep alive check is not utilized for the long polling transport" and I found a reference here that this indeed is disabled by default and the last comment on this issue is "...stops receiving communication coming from server..."

If I understand correctly we enable the client keep alive by setting: GlobalHost.Configuration.KeepAlive And we have set this, so still why does the client not detect connection death!

Community
  • 1
  • 1
Boscabouter
  • 51
  • 4
  • Do you see a new connection being created? Because it sounds like a new one exists that the Client is using for incoming traffic, but the Invoke is still using the old dead connection. – Andrew Gale Feb 16 '17 at 15:37
  • The client is still using the old connection, in the Hub there is an OnDisconnected, but never a new OnConnected or OnReconnected. However I find it strange that the hub answers incomming messages with an "I" but thinks the connection is dead. Just found this which seems the same, but was closed in milestone 2.1.2 and we are using version 2.2: [Issue 3259](https://github.com/SignalR/SignalR/issues/3259) The reconnection process is never triggered on client-side and it stops receiving any communication coming from server – Boscabouter Feb 17 '17 at 06:21
  • The same is happening to me. If the client suffers a short disconnection it can send messages to the server but the server can't send them messages and the event "disconnected" is fired on the server. Where you able to find any solution? – Jano May 14 '19 at 23:30
  • Hi Jano, we essentially did the same as Andrew, just reinitialized the connection. – Boscabouter May 16 '19 at 06:29
0

Not really the best solution, but I ended up just reinitializing the connection when the state changes to "Reconnecting". Hopefully Garbage Collection will take care of the original connection.

Hopefully this issue will be addressed eventually.

Andrew Gale
  • 101
  • 1
  • 4