[
https://issues.apache.org/jira/browse/GUACAMOLE-1015?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17104859#comment-17104859
]
AJ Funk commented on GUACAMOLE-1015:
------------------------------------
[~vnick] my understanding of why the issue isn't caught by the Guacamole Client
is because a WebSocket connection-time error causes a _dispatched event_, not a
_thrown value_.
Initially, we were not even getting a stack trace with the error. Once I
realized the WebSocket "errors" are not actual errors, we added this extra
logging to pin down the issue.
I'm pretty confident this is a Guac issue, as we are not doing anything special
with Guacamole Client. Whenever this error occurs and we log the various state
values, we always find them out of sync. Applying the patch directly to the
library fixed the issue, and unless I'm missing something, it seems to make
more sense to check that the websocket is connected rather than relying on
Guac's internal state handling of its WebSocketTunnel.
It's worth noting that this error does not actually interfere with any
functionality - the WebSocketTunnel still works fine, but it spams these error
messages pretty often without the patch.
> tunnel and websocket states out of sync
> ---------------------------------------
>
> Key: GUACAMOLE-1015
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-1015
> Project: Guacamole
> Issue Type: Bug
> Components: guacamole-common-js
> Affects Versions: 1.1.0
> Reporter: AJ Funk
> Priority: Minor
>
> When using the WebSocketTunnel, we are constantly seeing the error:
> "InvalidStateError: Failed to execute 'send' on 'WebSocket': Still in
> CONNECTING state." being thrown.
> The identify the issue, we added some extra logging information by overriding
> the sendMessage method and wrapping it with a try/catch like this:
> {code:java}
> const websocketTunnel = this.websocket = new
> Guacamole.WebSocketTunnel(`wss://${domain}/guacamole/${guacWsPort}`);
> const guac = this.rfb = new Guacamole.Client(this.websocket);
> // wrap sendMessage with a try/catch for debugging
> const originalTunnelSendMessage = websocketTunnel.sendMessage;
> this.websocket.sendMessage = (...args) => {
> try {
> originalTunnelSendMessage.apply(this.websocket, args);
> } catch (e) {
> if (window.Sentry) {
> const clientState = guac.getState();
> const tunnelState = websocketTunnel.state;
> const socketState = websocketTunnel.socket.readyState;
> window.Sentry.withScope(scope => {
> scope.setTag("origin", "guac socket");
> scope.setExtra("args", args);
> scope.setExtra("clientState", clientState);
> scope.setExtra("tunnelState", tunnelState);
> scope.setExtra("socketReadyState", socketState);
> window.Sentry.captureException(e);
> });
> }
> }
> }
> {code}
> (we use [https://sentry.io|https://sentry.io/] to capture exceptions)
> This provided the following values:
> clientState: 2 (STATE_WAITING)
> tunnelState: 3 (UNSTABLE)
> socketReadyState: 0 (CONNECTING)
> We managed to apply a patch to silence this error. On this line
> [https://guacamole.apache.org/doc/1.1.0/guacamole-common-js/Tunnel.js.html#line379]
> we changed
> {code:java}
> if (!tunnel.isConnected()){code}
> to check the socket's state instead of the tunnel's:
> {code:java}
> if (!socket || socket.readyState !== WebSocket.OPEN ){code}
>
> We determined that this error was non-critical since it did not disrupt the
> client's websocket connection, but it caused a lot of noise with thousands of
> error events.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
