taoensso / sente

Realtime web comms library for Clojure/Script
https://www.taoensso.com/sente
Eclipse Public License 1.0
1.74k stars 193 forks source link

Sente retrying connection after disconnection #254

Closed danielcompton closed 8 years ago

danielcompton commented 8 years ago

I've noticed that when I disconnect a websocket connection when it is trying to connect, it makes one more reconnect attempt after the disconnect. I've attached a log below from the Sente example project showing this.

I've just pushed a branch https://github.com/ptaoussanis/sente/tree/reconnect-example which adds a disconnect and reconnect button in the example project for you to easily experiment with.

• • • • • • • • • • • • 
ClojureScript appears to have loaded correctly.
Randomly selected chsk type: :auto
Channel socket successfully established!: {:type :ws, :open? true, :ever-opened? true, :uid :taoensso.sente/nil-uid, :csrf-token "nTMubvuBwNf8UE9kClEuvyaLa4SqD6xGVnZ9Cvl4u5TrJPicHaicBqqOGG5NGFtgsei7mr2ZXf5QYLOe", :handshake-data nil, :first-open? true}
Handshake: [:taoensso.sente/nil-uid "nTMubvuBwNf8UE9kClEuvyaLa4SqD6xGVnZ9Cvl4u5TrJPicHaicBqqOGG5NGFtgsei7mr2ZXf5QYLOe" nil true]
Push event from server: [:some/broadcast {:what-is-this "An async broadcast pushed from server", :how-often "Every 10 seconds", :i 2, :to-whom :taoensso.sente/nil-uid}]
Push event from server: [:some/broadcast {:what-is-this "An async broadcast pushed from server", :how-often "Every 10 seconds", :i 3, :to-whom :taoensso.sente/nil-uid}]
>>>>>>>>>>>>>>> Ctrl-C on the server
Channel socket state change: {:type :ws, :open? false, :ever-opened? true, :uid :taoensso.sente/nil-uid, :csrf-token "nTMubvuBwNf8UE9kClEuvyaLa4SqD6xGVnZ9Cvl4u5TrJPicHaicBqqOGG5NGFtgsei7mr2ZXf5QYLOe", :handshake-data nil, :first-open? false, :last-ws-close {:uuid "454ddc3c-490f-4181-87a5-72f1aff85ccf", :ev #object[CloseEvent [object CloseEvent]], :clean? false, :code 1006, :reason ""}}
Channel socket state change: {:type :ws, :open? false, :ever-opened? true, :uid :taoensso.sente/nil-uid, :csrf-token "nTMubvuBwNf8UE9kClEuvyaLa4SqD6xGVnZ9Cvl4u5TrJPicHaicBqqOGG5NGFtgsei7mr2ZXf5QYLOe", :handshake-data nil, :first-open? false, :last-ws-close {:uuid "9a2d01b5-bd34-4a0b-9632-6eabb895fcac", :ev #object[CloseEvent [object CloseEvent]], :clean? false, :code 1006, :reason ""}}
Channel socket state change: {:type :ws, :open? false, :ever-opened? true, :uid :taoensso.sente/nil-uid, :csrf-token "nTMubvuBwNf8UE9kClEuvyaLa4SqD6xGVnZ9Cvl4u5TrJPicHaicBqqOGG5NGFtgsei7mr2ZXf5QYLOe", :handshake-data nil, :first-open? false, :last-ws-close {:uuid "6fd2dec9-500a-415a-8ed1-33d9a937ccaf", :ev #object[CloseEvent [object CloseEvent]], :clean? false, :code 1006, :reason ""}}
Channel socket state change: {:type :ws, :open? false, :ever-opened? true, :uid :taoensso.sente/nil-uid, :csrf-token "nTMubvuBwNf8UE9kClEuvyaLa4SqD6xGVnZ9Cvl4u5TrJPicHaicBqqOGG5NGFtgsei7mr2ZXf5QYLOe", :handshake-data nil, :first-open? false, :last-ws-close {:uuid "d125e920-9ab9-4098-ba79-bd55085823f1", :ev #object[CloseEvent [object CloseEvent]], :clean? false, :code 1006, :reason ""}}
Disconnecting
Channel socket state change: {:type :ws, :open? false, :ever-opened? true, :uid :taoensso.sente/nil-uid, :csrf-token "nTMubvuBwNf8UE9kClEuvyaLa4SqD6xGVnZ9Cvl4u5TrJPicHaicBqqOGG5NGFtgsei7mr2ZXf5QYLOe", :handshake-data nil, :first-open? false, :last-ws-close {:uuid "533a802e-9b61-4d84-b696-dc183e6152b9", :ev #object[CloseEvent [object CloseEvent]], :clean? false, :code 1006, :reason ""}}

I've had a look at the reconnect code, and I can't quite figure out where the checks should go to stop this from happening.

ptaoussanis commented 8 years ago

Hey Daniel, just to clarify what I'll be looking for-

  1. The client successfully connects to the server.
  2. While the client is connected, you issue a client-side chsk-disconnect! call.
  3. This causes the client to correctly disconnect.
  4. But after disconnecting, the client still attempts to auto reconnect (it shouldn't).

That correct? This part is tripping me up:

when I disconnect a websocket connection when it is trying to connect

Are you implying this only happens if you issue chsk-disconnect! while a normal connection attempt is literally in progress? Should the above instead be adjusted to-

  1. The client is in the process of connecting to the server.
  2. Before the client is successfully connected, you issue a client-side chsk-disconnect! call.
  3. This causes the client to correctly disconnect.
  4. But after disconnecting, the client still attempts to auto reconnect (it shouldn't).

I've just pushed a branch

Great, that'll be helpful. Will just wait for you to confirm what I'm looking for.

Thanks, cheers :-)

ptaoussanis commented 8 years ago

Just to confirm, you're not seeing a log message like Permanently downgrading :auto chsk -> :ajax?

I.e. no chance that what's happening is that the WebSocket->Ajax fallback is kicking in? (It shouldn't, but may be buggy).

danielcompton commented 8 years ago

Just to confirm, you're not seeing a log message like Permanently downgrading :auto chsk -> :ajax?

Nope, nothing about downgrading to ajax, and devtools shows a ws connection. The steps to reproduce are:

  1. Start up server
  2. Reload until you get a WS connection
  3. Wait for a few seconds to get a ping
  4. Shut down the server (Ctrl+C), observe the client start to try reconnecting
  5. Wait a few retries, then click the "Disconnect" button in the browser
  6. Observe that there is one more reconnect attempt after the disconnect is clicked.
ptaoussanis commented 8 years ago

The steps to reproduce are

Thanks, this framing makes the problem immediately clear. The critical observation was 4 preceding 5. Will fix, thanks.

ptaoussanis commented 8 years ago

Just pushed [com.taoensso/sente "1.11.0-SNAPSHOT"] to Clojars. When you have some time, may I ask you to confirm that this is resolved?

Would also be happy to accept a PR that brings the disconnect/reconnect buttons to the ref example.

Thanks

danielcompton commented 8 years ago

Sure thing, will look at both of your changes on Monday. Thanks!

danielcompton commented 8 years ago

I can confirm that your commit fixes this. Thanks!