Details
-
Bug
-
Status: Resolved
-
Minor
-
Resolution: Fixed
-
0.9.13-incubating
-
None
Description
Previously asked on the mailing list. Opening an issue to submit a PR.
-------
Tunnel implementations (WebSocket and HTTP) only handle the closing flow once. It's not that they're not re-usable, but if they are in a CLOSED state and another connect() call is issued, it doesn't handle the second failure properly. Making it impossible to automatically know about a subsequent error.
On the second failure, the onerror and onstatechange callbacks are not called. For example, this is log output of the behavior:
// Connecting to a running proxy
guac.onstatechange 1 STATE_CONNECTING
guac.onstatechange 2 STATE_WAITING
tunnel.onstatechange 1 OPEN
guac.onstatechange 3 STATE_CONNECTED
// Killing proxy/guacd
tunnel.onerror Guacamole.Status {code: NaN, message: "Shutdown", isError: ƒ}
tunnel.onstatechange 2 CLOSED
Tunnel disconnected, place retry handling here
// Reconnecting by calling connect on the same Client instance
guac.onstatechange 1 STATE_CONNECTING
guac.onstatechange 2 STATE_WAITING
WebSocket connection to 'ws://localhost:8080/websocket..' failed: Error in connection establishment: net::ERR_CONNECTION_REFUSED
// No state change from tunnel, it will just hang like this
I was wondering how the Guacamole application handles this since it does work as expected. I saw that it doesn't really re-use the client, but creates a new one.