JS client can't receive messages after reconnected for network disconnect and re-connected #1144

Closed
Xiaohongt opened this Issue Dec 15, 2012 · 25 comments

Projects

None yet

5 participants

@Xiaohongt
SignalR member

Repro :

  1. You can map the AspNet Sample to IIS website, and build the web site
  2. on remote machine, use webSockets or foreverFrame or SSE transport to request the IIS website Raw/default.aspx
  3. disconnect the network cable about 31 second, and reconnecting event raise
  4. re-connect the network cable, and connection reconnected
  5. click the broadcast button, e.g. type aaa and click broadcast button
  6. you don't see that the connections receive message
  7. open another browser to use webSockets or foreverFrame or SSE to request the IIS website Raw/default.aspx
  8. on the first reconnected connection, type aaa111 and click broadcast button
  9. you can see that the second connection can receive the message, but the first connection still can't receive the message.

Note:
This only repro after reconnected for network disconnect and re-connected.
This doesn't repro after reconnected for server process stop and server process re-start.

this is regression from RC1, ( in RC1 it doesn't repro)

@Claytonious

We are seeing this one, too.

An even easier way to reproduce it is to use an iPad. Make sure it connects via the webSocket transport. Then, instead of unplugging any network cables, simply put the iPad to sleep for about 5 seconds. Turn it back on and you will still be on the web page but will now observe this same issue. SignalR correctly recognizes that the websocket was was disconnected and it correctly reconnects (you can see a reconnect from signalR if you listen for that event), but the client will never receive messages again. It can still send them, though.

Our QA first discovered this when their mobile devices were accidentally going to sleep while they were using our app. But the broader issue is that apparently any reconnect while on webSockets (regardless of the reason - sleeping devices is just one easy test path to use) leaves the client unable to ever receive messages again.

@davidfowl
SignalR member

@Claytonious Can you turn logging on and paste the console log output in here?

@davidfowl
SignalR member

@Xiaohongt Can you do the same?

@Xiaohongt Xiaohongt was assigned Dec 16, 2012
@Claytonious

Here is the client-side log below. When you see the Keep alive missed and eventual reconnect, that is me deliberately taking the server off of the network for a moment. You can see that the client does reconnect, but after that, hitting the "Broadcast" button does NOT show any messages anymore.

Is there some server-side logging I can pull, too?

(BTW, this was deployed from the dev branch to IIS 8 running in Windows 8).

Also, you notice in this example I was connecting by IP instead of hostname. That's only because I have to from where I am right now, but the same issue repros the same way even with a proper hostname for the URL.

[21:21:25 GMT-0700 (MST)] SignalR: Negotiating with '../raw-connection/negotiate'.
jquery.signalR.js:54[21:21:25 GMT-0700 (MST)] SignalR: Connecting to websocket endpoint 'ws://192.168.1.248/SignalRSamples/raw-connection/connect?transport=webSockets&connectionId=b90d8bf2-4207-4935-bb32-a0c59cd22fc1&tid=9'
jquery.signalR.js:54[21:21:25 GMT-0700 (MST)] SignalR: Websocket opened
jquery.signalR.js:54[21:21:25 GMT-0700 (MST)] SignalR: Now monitoring keep alive with a warning timeout of 20000 and a connection lost timeout of 30000
jquery.signalR.js:54[21:21:52 GMT-0700 (MST)] SignalR: Keep alive has been missed, connection may be dead/slow.
jquery.signalR.js:54[21:22:02 GMT-0700 (MST)] SignalR: Keep alive timed out. Notifying transport that connection has been lost.
jquery.signalR.js:54[21:22:04 GMT-0700 (MST)] SignalR: Closing the Websocket
jquery.signalR.js:54[21:22:04 GMT-0700 (MST)] SignalR: Websocket reconnecting
jquery.signalR.js:54[21:22:04 GMT-0700 (MST)] SignalR: Connecting to websocket endpoint 'ws://192.168.1.248/SignalRSamples/raw-connection?transport=webSockets&connectionId=b90d8bf2-4207-4935-bb32-a0c59cd22fc1&messageId=B%2CD%7CH%2C1%7CI%2C0%7CE%2C0&groups=%5B%22Microsoft.AspNet.SignalR.Samples.Raw.RawConnection.foo%22%5D&tid=2'
jquery.signalR.js:54[21:22:24 GMT-0700 (MST)] SignalR: Websocket opened

@Claytonious

I also added my own client-side logging in jquery.signalR.js in the connection.socket.onmessage handler, and in this scenario of the reconnected web socket, the client web socket truly does not ever receive any messages. So the problem is not some client-side plumbing of the event not reaching a handler, but seems to be a server-side problem (like the client is no longer a part of the hub or group he was on, or is indefinitely blocked, etc.)

@davidfowl
SignalR member

For server side logging, you should be able to mimic the system.diagnostics section here

https://github.com/SignalR/SignalR/blob/master/samples/Microsoft.AspNet.SignalR.Hosting.AspNet.Samples/Web.config

@Claytonious

OK, getting it...

@Claytonious
SignalR.Transports.TransportHeartBeat Information: 0 : Connection is New=(http://192.168.1.248/SignalRSamples/raw-connection?transport=webSockets&connectionId=7d2d5cac-f824-4e4d-8d9e-f74b3b1de985&messageId=B%2C4|F%2C1|G%2C0|E%2C0&groups=["Microsoft.AspNet.SignalR.Samples.Raw.RawConnection.foo"]&tid=6).
    ProcessId=60
    ThreadId=46
    DateTime=2012-12-17T04:59:01.8203967Z
SignalR.Transports.TransportHeartBeat Information: 0 : KeepAlive(7d2d5cac-f824-4e4d-8d9e-f74b3b1de985)
    ProcessId=60
    ThreadId=53
    DateTime=2012-12-17T04:59:21.6396433Z
SignalR.Transports.TransportHeartBeat Information: 0 : Removing connection 7d2d5cac-f824-4e4d-8d9e-f74b3b1de985
    ProcessId=60
    ThreadId=55
    DateTime=2012-12-17T04:59:22.9259615Z
SignalR.Transports.TransportHeartBeat Information: 0 : Connection is New=(http://192.168.1.248/SignalRSamples/raw-connection/connect?transport=webSockets&connectionId=dfa37c2b-ae46-40cd-ba18-d08dc8790b83&tid=10).
    ProcessId=60
    ThreadId=32
    DateTime=2012-12-17T04:59:23.9024982Z
SignalR.Transports.TransportHeartBeat Information: 0 : KeepAlive(dfa37c2b-ae46-40cd-ba18-d08dc8790b83)
    ProcessId=60
    ThreadId=46
    DateTime=2012-12-17T04:59:41.6653230Z
SignalR.Transports.TransportHeartBeat Information: 0 : dfa37c2b-ae46-40cd-ba18-d08dc8790b83 is dead
    ProcessId=60
    ThreadId=53
    DateTime=2012-12-17T05:00:01.6786759Z
SignalR.Transports.TransportHeartBeat Information: 0 : dfa37c2b-ae46-40cd-ba18-d08dc8790b83 is dead
    ProcessId=60
    ThreadId=53
    DateTime=2012-12-17T05:00:11.6797119Z
SignalR.Transports.TransportHeartBeat Information: 0 : dfa37c2b-ae46-40cd-ba18-d08dc8790b83 is dead
    ProcessId=60
    ThreadId=55
    DateTime=2012-12-17T05:00:21.6926507Z
SignalR.Transports.TransportHeartBeat Information: 0 : Connection exists. Closing previous connection. Old=(False, http://192.168.1.248/SignalRSamples/raw-connection/connect?transport=webSockets&connectionId=dfa37c2b-ae46-40cd-ba18-d08dc8790b83&tid=10) New=(http://192.168.1.248/SignalRSamples/raw-connection?transport=webSockets&connectionId=dfa37c2b-ae46-40cd-ba18-d08dc8790b83&messageId=B%2C5|F%2C1|G%2C0|E%2C0&groups=["Microsoft.AspNet.SignalR.Samples.Raw.RawConnection.foo"]&tid=8)
    ProcessId=60
    ThreadId=41
    DateTime=2012-12-17T05:00:26.3810401Z

@davidfowl
SignalR member

Remove this traceOutputOptions="ThreadId, DateTime" and try to send to the connection after reconnecting.

@Claytonious
SignalR.Transports.TransportHeartBeat Information: 0 : Connection is New=(http://192.168.1.248/SignalRSamples/raw-connection?transport=webSockets&connectionId=8ed9d8cd-b607-4060-b9cd-a4b80cdeadae&messageId=B%2C3|F%2C1|G%2C0|E%2C0&groups=["Microsoft.AspNet.SignalR.Samples.Raw.RawConnection.foo"]&tid=10).
SignalR.Transports.TransportHeartBeat Information: 0 : Removing connection 8ed9d8cd-b607-4060-b9cd-a4b80cdeadae
SignalR.Transports.TransportHeartBeat Information: 0 : Connection is New=(http://192.168.1.248/SignalRSamples/raw-connection/connect?transport=webSockets&connectionId=f6b4073d-6a32-4304-8962-0df3aab13f1a&tid=3).
SignalR.Transports.TransportHeartBeat Information: 0 : KeepAlive(f6b4073d-6a32-4304-8962-0df3aab13f1a)
SignalR.Transports.TransportHeartBeat Information: 0 : f6b4073d-6a32-4304-8962-0df3aab13f1a is dead
SignalR.Transports.TransportHeartBeat Information: 0 : f6b4073d-6a32-4304-8962-0df3aab13f1a is dead
SignalR.Transports.TransportHeartBeat Information: 0 : f6b4073d-6a32-4304-8962-0df3aab13f1a is dead
SignalR.Transports.TransportHeartBeat Information: 0 : Connection exists. Closing previous connection. Old=(False, http://192.168.1.248/SignalRSamples/raw-connection/connect?transport=webSockets&connectionId=f6b4073d-6a32-4304-8962-0df3aab13f1a&tid=3) New=(http://192.168.1.248/SignalRSamples/raw-connection?transport=webSockets&connectionId=f6b4073d-6a32-4304-8962-0df3aab13f1a&messageId=B%2C4|F%2C1|G%2C0|E%2C0&groups=["Microsoft.AspNet.SignalR.Samples.Raw.RawConnection.foo"]&tid=5)
SignalR.Transports.TransportHeartBeat Information: 0 : KeepAlive(f6b4073d-6a32-4304-8962-0df3aab13f1a)
SignalR.Transports.TransportHeartBeat Information: 0 : KeepAlive(f6b4073d-6a32-4304-8962-0df3aab13f1a)
SignalR.Transports.WebSocketTransport Information: 0 : OnDisconnect(8ed9d8cd-b607-4060-b9cd-a4b80cdeadae)
SignalR.Transports.WebSocketTransport Information: 0 : End(8ed9d8cd-b607-4060-b9cd-a4b80cdeadae)
SignalR.Transports.WebSocketTransport Information: 0 : Cancel(8ed9d8cd-b607-4060-b9cd-a4b80cdeadae)
SignalR.Transports.WebSocketTransport Information: 0 : DrainWrites(8ed9d8cd-b607-4060-b9cd-a4b80cdeadae)
SignalR.Transports.WebSocketTransport Information: 0 : EndRequest(8ed9d8cd-b607-4060-b9cd-a4b80cdeadae)
SignalR.Transports.WebSocketTransport Information: 0 : End(f6b4073d-6a32-4304-8962-0df3aab13f1a)
SignalR.Transports.WebSocketTransport Information: 0 : Cancel(f6b4073d-6a32-4304-8962-0df3aab13f1a)
SignalR.Transports.WebSocketTransport Information: 0 : DrainWrites(f6b4073d-6a32-4304-8962-0df3aab13f1a)
SignalR.Transports.WebSocketTransport Information: 0 : EndRequest(f6b4073d-6a32-4304-8962-0df3aab13f1a)
SignalR.MessageBus Information: 0 : Creating a worker, allocated=1, busy=0
SignalR.MessageBus Information: 0 : No need to add a worker because all allocated workers are not busy, allocated=1, busy=0
SignalR.MessageBus Information: 0 : Work(8ed9d8cd-b607-4060-b9cd-a4b80cdeadae)
SignalR.MessageBus Information: 0 : Work(0f1cd982-cabb-4e54-8fa0-a6dd5cfbad8e)
SignalR.MessageBus Information: 0 : No need to add a worker because all allocated workers are not busy, allocated=1, busy=0
SignalR.MessageBus Information: 0 : Work(8ed9d8cd-b607-4060-b9cd-a4b80cdeadae)
SignalR.MessageBus Information: 0 : No need to add a worker because all allocated workers are not busy, allocated=1, busy=0
SignalR.MessageBus Information: 0 : Work(0f1cd982-cabb-4e54-8fa0-a6dd5cfbad8e)
SignalR.MessageBus Information: 0 : No need to add a worker because all allocated workers are not busy, allocated=1, busy=0
SignalR.MessageBus Information: 0 : Work(f6b4073d-6a32-4304-8962-0df3aab13f1a)
SignalR.MessageBus Information: 0 : Work(f6b4073d-6a32-4304-8962-0df3aab13f1a)
SignalR.MessageBus Information: 0 : No need to add a worker because all allocated workers are not busy, allocated=1, busy=0
SignalR.MessageBus Information: 0 : Work(f6b4073d-6a32-4304-8962-0df3aab13f1a)
SignalR.MessageBus Information: 0 : No need to add a worker because all allocated workers are not busy, allocated=1, busy=0
SignalR.MessageBus Information: 0 : No need to add a worker because all allocated workers are not busy, allocated=1, busy=0
SignalR.MessageBus Information: 0 : Work(f6b4073d-6a32-4304-8962-0df3aab13f1a)
SignalR.MessageBus Information: 0 : Work(0f1cd982-cabb-4e54-8fa0-a6dd5cfbad8e)
SignalR.MessageBus Information: 0 : RemoveTopic(ACK_8ed9d8cd-b607-4060-b9cd-a4b80cdeadae)
SignalR.MessageBus Information: 0 : RemoveTopic(8ed9d8cd-b607-4060-b9cd-a4b80cdeadae)
@Claytonious

Should we be surprised to see "Connection exists. Closing previous connection"? Shouldn't the original one have had RemoveConnection() called on it when it first went bad?

@davidfowl
SignalR member

Nope, it depends on how long you waited before reconnecting. If it's within the DisconnectTimeout then that's expected. It looks like you have 2 connections here? Which one is the important one? Can you come to jabbr (https://jabbr.net/#/rooms/signalr), having discussions on bugs is unproductive. If not, I can just look into it.

@Claytonious

Sure, omw.

@Xiaohongt
SignalR member

here is the server side log, 8cdbbb27-1daa-4b04-99cf-ef9139055569 is the first connection and reconnected in the repro of the isse, 8a9eefe3-a2a0-4f44-8b5d-8b8c1703db09 is the second connection in the repro:

SignalR.Transports.TransportHeartBeat Information: 0 : Connection is New=(http://xiaota003-vm02/Sample/raw-connection/connect?transport=webSockets&connectionId=8cdbbb27-1daa-4b04-99cf-ef9139055569&tid=10).
    ThreadId=11
    DateTime=2012-12-17T20:21:20.8901008Z
SignalR.MessageBus Information: 0 : Creating a worker, allocated=1, busy=0
    ThreadId=11
    DateTime=2012-12-17T20:21:20.9213006Z
SignalR.MessageBus Information: 0 : Work(f3666fa0-a3ad-4c0b-bc0f-bdfa374b5fb2)
    ThreadId=15
    DateTime=2012-12-17T20:21:20.9213006Z
SignalR.MessageBus Information: 0 : Creating a worker, allocated=2, busy=1
    ThreadId=11
    DateTime=2012-12-17T20:21:20.9369020Z
SignalR.MessageBus Information: 0 : Work(8cdbbb27-1daa-4b04-99cf-ef9139055569)
    ThreadId=9
    DateTime=2012-12-17T20:21:20.9369020Z
SignalR.MessageBus Information: 0 : Work(8cdbbb27-1daa-4b04-99cf-ef9139055569)
    ThreadId=9
    DateTime=2012-12-17T20:21:21.1241025Z
SignalR.Transports.TransportHeartBeat Information: 0 : KeepAlive(8cdbbb27-1daa-4b04-99cf-ef9139055569)
    ThreadId=10
    DateTime=2012-12-17T20:21:40.8271262Z
SignalR.Transports.TransportHeartBeat Information: 0 : 8cdbbb27-1daa-4b04-99cf-ef9139055569 is dead
    ThreadId=12
    DateTime=2012-12-17T20:21:50.8424394Z
SignalR.Transports.TransportHeartBeat Information: 0 : 8cdbbb27-1daa-4b04-99cf-ef9139055569 is dead
    ThreadId=10
    DateTime=2012-12-17T20:22:00.8421534Z
SignalR.Transports.TransportHeartBeat Information: 0 : Connection exists. Closing previous connection. Old=(False, http://xiaota003-vm02/Sample/raw-connection/connect?transport=webSockets&connectionId=8cdbbb27-1daa-4b04-99cf-ef9139055569&tid=10) New=(http://xiaota003-vm02/Sample/raw-connection?transport=webSockets&connectionId=8cdbbb27-1daa-4b04-99cf-ef9139055569&messageId=B%2C1|C%2C1|D%2C0|E%2C0&groups=["Microsoft.AspNet.SignalR.Samples.Raw.RawConnection.foo"]&tid=2)
    ThreadId=10
    DateTime=2012-12-17T20:22:08.3926390Z
SignalR.Transports.WebSocketTransport Information: 0 : End(8cdbbb27-1daa-4b04-99cf-ef9139055569)
    ThreadId=10
    DateTime=2012-12-17T20:22:08.3926390Z
SignalR.Transports.WebSocketTransport Information: 0 : Cancel(8cdbbb27-1daa-4b04-99cf-ef9139055569)
    ThreadId=6
    DateTime=2012-12-17T20:22:08.3926390Z
SignalR.MessageBus Information: 0 : No need to add a worker because all allocated workers are not busy, allocated=2, busy=0
    ThreadId=10
    DateTime=2012-12-17T20:22:08.4082382Z
SignalR.MessageBus Information: 0 : Work(8cdbbb27-1daa-4b04-99cf-ef9139055569)
    ThreadId=15
    DateTime=2012-12-17T20:22:08.4082382Z
SignalR.MessageBus Information: 0 : No need to add a worker because all allocated workers are not busy, allocated=2, busy=1
    ThreadId=10
    DateTime=2012-12-17T20:22:08.4082382Z
SignalR.MessageBus Information: 0 : Work(f3666fa0-a3ad-4c0b-bc0f-bdfa374b5fb2)
    ThreadId=9
    DateTime=2012-12-17T20:22:08.4082382Z
SignalR.Transports.WebSocketTransport Information: 0 : DrainWrites(8cdbbb27-1daa-4b04-99cf-ef9139055569)
    ThreadId=6
    DateTime=2012-12-17T20:22:08.4082382Z
SignalR.MessageBus Information: 0 : No need to add a worker because all allocated workers are not busy, allocated=2, busy=0
    ThreadId=10
    DateTime=2012-12-17T20:22:08.4082382Z
SignalR.MessageBus Information: 0 : Work(8cdbbb27-1daa-4b04-99cf-ef9139055569)
    ThreadId=15
    DateTime=2012-12-17T20:22:08.4082382Z
SignalR.Transports.WebSocketTransport Information: 0 : EndRequest(8cdbbb27-1daa-4b04-99cf-ef9139055569)
    ThreadId=6
    DateTime=2012-12-17T20:22:08.4082382Z
SignalR.Transports.TransportHeartBeat Information: 0 : KeepAlive(8cdbbb27-1daa-4b04-99cf-ef9139055569)
    ThreadId=6
    DateTime=2012-12-17T20:22:30.8880934Z
SignalR.Transports.TransportHeartBeat Information: 0 : KeepAlive(8cdbbb27-1daa-4b04-99cf-ef9139055569)
    ThreadId=10
    DateTime=2012-12-17T20:22:50.9187216Z
SignalR.Transports.TransportHeartBeat Information: 0 : Connection is New=(http://xiaota003-vm02/Sample/raw-connection/connect?transport=webSockets&connectionId=8a9eefe3-a2a0-4f44-8b5d-8b8c1703db09&tid=10).
    ThreadId=12
    DateTime=2012-12-17T20:22:56.4567824Z
SignalR.MessageBus Information: 0 : No need to add a worker because all allocated workers are not busy, allocated=2, busy=0
    ThreadId=12
    DateTime=2012-12-17T20:22:56.4567824Z
SignalR.MessageBus Information: 0 : Work(f3666fa0-a3ad-4c0b-bc0f-bdfa374b5fb2)
    ThreadId=9
    DateTime=2012-12-17T20:22:56.4567824Z
SignalR.MessageBus Information: 0 : No need to add a worker because all allocated workers are not busy, allocated=2, busy=0
    ThreadId=12
    DateTime=2012-12-17T20:22:56.4567824Z
SignalR.MessageBus Information: 0 : Work(8a9eefe3-a2a0-4f44-8b5d-8b8c1703db09)
    ThreadId=15
    DateTime=2012-12-17T20:22:56.4567824Z
SignalR.MessageBus Information: 0 : Work(8a9eefe3-a2a0-4f44-8b5d-8b8c1703db09)
    ThreadId=15
    DateTime=2012-12-17T20:22:56.4567824Z
SignalR.MessageBus Information: 0 : No need to add a worker because all allocated workers are not busy, allocated=2, busy=0
    ThreadId=12
    DateTime=2012-12-17T20:23:04.2412705Z
SignalR.MessageBus Information: 0 : Work(8a9eefe3-a2a0-4f44-8b5d-8b8c1703db09)
    ThreadId=9
    DateTime=2012-12-17T20:23:04.2412705Z
SignalR.Transports.TransportHeartBeat Information: 0 : KeepAlive(8cdbbb27-1daa-4b04-99cf-ef9139055569)
    ThreadId=11
    DateTime=2012-12-17T20:23:10.9493472Z
SignalR.Transports.TransportHeartBeat Information: 0 : KeepAlive(8a9eefe3-a2a0-4f44-8b5d-8b8c1703db09)
    ThreadId=10
    DateTime=2012-12-17T20:23:20.9646604Z
SignalR.MessageBus Information: 0 : No need to add a worker because all allocated workers are not busy, allocated=2, busy=0
    ThreadId=12
    DateTime=2012-12-17T20:23:27.7195359Z
SignalR.MessageBus Information: 0 : Work(8a9eefe3-a2a0-4f44-8b5d-8b8c1703db09)
    ThreadId=15
    DateTime=2012-12-17T20:23:27.7195359Z
SignalR.Transports.TransportHeartBeat Information: 0 : KeepAlive(8cdbbb27-1daa-4b04-99cf-ef9139055569)
    ThreadId=12
    DateTime=2012-12-17T20:23:30.9799722Z
SignalR.Transports.TransportHeartBeat Information: 0 : KeepAlive(8a9eefe3-a2a0-4f44-8b5d-8b8c1703db09)
    ThreadId=11
    DateTime=2012-12-17T20:23:40.9952883Z
SignalR.Transports.TransportHeartBeat Information: 0 : KeepAlive(8cdbbb27-1daa-4b04-99cf-ef9139055569)
    ThreadId=16
    DateTime=2012-12-17T20:23:51.0105997Z
SignalR.MessageBus Information: 0 : Dispoing the broker
    ThreadId=16
    DateTime=2012-12-17T20:24:00.2615040Z
SignalR.MessageBus Information: 0 : Disposed the broker
    ThreadId=16
    DateTime=2012-12-17T20:24:00.5267089Z
SignalR.Transports.WebSocketTransport Information: 0 : End(8cdbbb27-1daa-4b04-99cf-ef9139055569)
    ThreadId=16
    DateTime=2012-12-17T20:24:00.5267089Z
SignalR.Transports.WebSocketTransport Information: 0 : End(8a9eefe3-a2a0-4f44-8b5d-8b8c1703db09)
    ThreadId=16
    DateTime=2012-12-17T20:24:00.5267089Z
SignalR.Transports.WebSocketTransport Information: 0 : Cancel(8cdbbb27-1daa-4b04-99cf-ef9139055569)
    ThreadId=12
    DateTime=2012-12-17T20:24:00.5267089Z
SignalR.Transports.WebSocketTransport Information: 0 : DrainWrites(8cdbbb27-1daa-4b04-99cf-ef9139055569)
    ThreadId=12
    DateTime=2012-12-17T20:24:00.5267089Z
SignalR.Transports.WebSocketTransport Information: 0 : EndRequest(8cdbbb27-1daa-4b04-99cf-ef9139055569)
    ThreadId=12
    DateTime=2012-12-17T20:24:00.5267089Z
SignalR.Transports.WebSocketTransport Information: 0 : Cancel(8a9eefe3-a2a0-4f44-8b5d-8b8c1703db09)
    ThreadId=23
    DateTime=2012-12-17T20:24:00.5267089Z
SignalR.Transports.WebSocketTransport Information: 0 : DrainWrites(8a9eefe3-a2a0-4f44-8b5d-8b8c1703db09)
    ThreadId=23
    DateTime=2012-12-17T20:24:00.5267089Z
SignalR.Transports.WebSocketTransport Information: 0 : EndRequest(8a9eefe3-a2a0-4f44-8b5d-8b8c1703db09)
    ThreadId=23
    DateTime=2012-12-17T20:24:00.5267089Z
@davidfowl davidfowl was assigned Dec 17, 2012
@Claytonious

What does the change to "1-Ready" label on this guy mean? ;-)

@davidfowl
SignalR member

I actually can't reproduce this in the latest. I'm trying to disconnect my wifi on this site:

http://dfowlervm.cloudapp.net/sample/Raw/

@Claytonious

I can't reproduce it on that site, either, so maybe some other fixes have cleaned this up. Are you sure that site is allowing websocket transport? (I can't tell from the client side here on an iPad). I will get the latest code and try my local test again to confirm.

@davidfowl
SignalR member

Yup websokets is enabled on the site. Just look at the log 😄

@davidfowl
SignalR member

Marking this as done as it doesn't repro anymore.

@Xiaohongt
SignalR member

still repro

@Xiaohongt
SignalR member

webSockets doesn't repro this issue anymore, but foreverFrame and SSE transports still repro this issue

@halter73 halter73 added a commit that referenced this issue Jan 9, 2013
@halter73 halter73 Ensure Subscriptions are successfully added to Topics on reconnect.
Addresses issue #1144

Since the SCTS.Cancel uses UnsafeQueueUserWorkItem, old Subscriptions
are often not removed before new ones are added when reconnecting.
Topic.AddSubscription would then block the addition of reconnecting
Subscriptions, since reconnecting Subscriptions have the same Identities as
the yet undeleted old subscriptions.

This change removes the check inside of Topic.AddSubscription preventing
two Subscriptions with the same Identity from being subscribed to the topic
at once.
cdd3021
@davidfowl
SignalR member

Fixed in cdd3021. We're going to add a test for this tomorrow.

@Xiaohongt
SignalR member

verified

@Xiaohongt Xiaohongt closed this Jan 9, 2013
@th3nu11

I have the same behavior with long polling: turn off and restart wifi on phone (but I not receive events about connection state change).

When the connection start, I can call the method on server but I don't receive any notification from server!

@davidfowl
SignalR member

@th3nu11 That behavior is by design with longpolling since it doesn't support keep alive. That's always been the case unfortunately and there's no easy way to fix it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment