RobustSockJS connectivity issues caused by high client execution latency

Using the attached demo app:

client-hang.zip

Load it into SSOS or SSP, with reconnect on;. Use Ctrl+Alt+Shift+A in the browser to turn off all transports except xhr-polling, then reload.

Causing the app to hang for 10 seconds results in "RobustSockJS collision" messages. Hanging for 48 seconds results in "Discard position id too big" messages, and disconnection.

This demonstrates that SockJS, and by extension we, are not robust to the client's main thread being blocked for many seconds at a time. This in and of itself might not be that big of a problem, since we need to give up on the client at some point; but it's a problem right now because it's not at all clear to the app author or admin what they're doing wrong.

Start with the attached client-hang.zip demo and reproduce the issue in SSOS or SSP with “reconnect on;”, xhr-polling enabled, and the client main thread blocked for 10 and 48 seconds. Read the resulting “RobustSockJS collision” and “Discard position id too big” behavior. Done should include a defined, understandable outcome for app authors and administrators when client execution latency causes disconnection.