Skip to content

Realtime preferring long-polling over websocket with vue-left-menu on

One thing that I noticed is that with the vue-left-menu feature toggle on, the gitter-realtime-client -> halley likes to choose long-polling over websocket.

I dug into the Halley code with some separate console.log debugging and long-polling is just faster to respond because websocket not connected yet in this Promise.any which races them.

The halley code does have pool.reevaluate which is called when it initializes, when we dispatcher.selectTransport on handshake, and whenever we dispatcher._attemptSend via _triggerUp only if the state isn't already up. It never re-evaluates on receiving messages or tries to upgrade when another transport becomes available.

Since we raced the connections initially, it seems like we could pool.reevaluate after another transport connects

window.localStorage.debug = '' and instead console.log('_reselect final', transport.connectionType); the result.

Notice how connected websocket happens after everything is already selected (just too slow)

_reselect allowed: (2) ["websocket", "long-polling"]
connected long-polling
_reselect final long-polling
_reselect allowed: ["long-polling"]
_reselect final long-polling
_reselect allowed: ["long-polling"]
_reselect final long-polling
_reselect allowed: (2) ["websocket", "long-polling"]
+_reselect final long-polling
+connected websocket

Interestingly when I try to use our debug logging, window.localStorage.debug = 'halley:pool', it settles on websocket more 🤔 (probably just slowing it down a bit)

Notice how connected websocket(not selected) happens in the middle of selecting so it gets selected just fine

window.localStorage.debug = 'halley:pool'

halley:pool _reselect allowed: ["websocket","long-polling"] +0ms
_reselect allowed: (2) ["websocket", "long-polling"]
connected long-polling
halley:pool Selected transport long-polling +41ms
_reselect final long-polling
halley:pool _reselect allowed: ["long-polling"] +3ms
_reselect allowed: ["long-polling"]
halley:pool Selected transport long-polling +2ms
_reselect final long-polling
+connected websocket
halley:pool _reselect allowed: ["long-polling"] +449ms
_reselect allowed: ["long-polling"]
halley:pool Selected transport long-polling +1ms
_reselect final long-polling
halley:pool _reselect allowed: ["websocket","long-polling"] +3ms
_reselect allowed: (2) ["websocket", "long-polling"]
+halley:pool Selected transport websocket +0ms
+_reselect final websocket

The data still flows on long-polling but I am concerned with this change in usual behavior as I don't want this to hurt production. Plus it's weird that it doesn't use websockets

The same thing happens on beta and prod so it isn't necessarily a local dev being faster thing

Feature toggle

  1. Add the feature toggle, node ./scripts/utils/feature-toggle.js --name vue-left-menu --description "Left menu using Vue (alpha)"
  2. Enable the feature toggle

Spawned from my investigation in https://gitlab.com/gitlab-org/gitter/webapp/merge_requests/1431#note_183284494

cc @andrewn

Edited by Eric Eastwood