Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Sente retrying connection after disconnection #254

Closed
danielcompton opened this issue Aug 5, 2016 · 7 comments
Closed

Sente retrying connection after disconnection #254

danielcompton opened this issue Aug 5, 2016 · 7 comments
Assignees

Comments

@danielcompton
Copy link
Collaborator

danielcompton commented Aug 5, 2016

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
Copy link
Member

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
Copy link
Member

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
Copy link
Collaborator Author

danielcompton commented Aug 5, 2016

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
Copy link
Member

The steps to reproduce are

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

ptaoussanis added a commit that referenced this issue Aug 5, 2016
In-flight (waiting) retries weren't checking handle ownership
ptaoussanis added a commit that referenced this issue Aug 5, 2016
In-flight (waiting) retries weren't checking handle ownership
@ptaoussanis
Copy link
Member

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
Copy link
Collaborator Author

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

@danielcompton
Copy link
Collaborator Author

I can confirm that your commit fixes this. Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants