Open bgourlie opened 7 years ago
Thanks for the issue! Make sure it satisfies this checklist. My human colleagues will appreciate it!
Here is what to expect next, and if anyone wants to comment, keep these things in mind.
I have seen exponential backoff in chrome (just a few minutes ago), but seem to get a constant rate of about 5 retries per second in safari doing the same thing. Now I'm getting one request every 3 seconds in chrome.
I suspect that the behavior you’re witnessing is throttling enforced by the browser. It’s been a while since I debugged this issue, but that’s what I recall. On Sat, Dec 9, 2017 at 6:54 AM Filip Haglund notifications@github.com wrote:
I have seen exponential backoff in chrome (just a few minutes ago), but seem to get a constant rate of about 5 retries per second in safari doing the same thing. Now I'm getting one request every 3 seconds in chrome.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/elm-lang/websocket/issues/17#issuecomment-350461081, or mute the thread https://github.com/notifications/unsubscribe-auth/AA80zLNe8IeavykXOd4aRtOrxEJl_sAnks5s-oMKgaJpZM4L-l4V .
Elm Version: 0.18 OS: Mac OS X Browser: Chrome SSCCE:
Because this is a bug internal to the websocket library, it can't be illustrated in an isolated example. Here are the simplest steps to reproduce:
Websocket.elm
in theelm-stuff/packages/websocket/1.0.2
directory. Add log statements to this line and this line so that you can see when they are fired.Detailed description:
The
BadOpen
message is never dispatched, presumably because theDie
message is dispatched with every failed connect attempt. This appears to be happening because the native websocketonClose
handler is fired every failed connect attempt, and thenonSelfMsg
handles theDie
message, resetting the connection state.It appears that the browser itself does some sort of connection throttling, which may be why this issue has gone unnoticed.