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
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
- Add the feature toggle,
node ./scripts/utils/feature-toggle.js --name vue-left-menu --description "Left menu using Vue (alpha)"
- Enable the feature toggle
Spawned from my investigation in https://gitlab.com/gitlab-org/gitter/webapp/merge_requests/1431#note_183284494
cc @andrewn