finding out the reason for Web Socket disconnect happened

Question

I am using Jetty Web sockets in my Application with Jetty 7 as our Server.

In our Application, data will be continuously flowing for every 1 second through web Socket , and as per our application design , if the Socket is idle for 4 minutes then the Socket will be disconnected.

Right now we are experiencing web Socket disconnects in our Application, I am unable to find out the reason for Web Socket disconnect reason, is this because the Socket is idle for 4 minutes or Something happened at the network level (I mean load balancer , firewall --etc )

For every disconnect , inside Jetty the reason code as 1006 (chrome)

Please let me know how can i find out the actual reason for disconnect happened?

Is there any way i can monitor the web socket traffic?

I have tried using the Chrome debugger tools Websocket tab to monitor the traffic , but once it disconnected i have no cluse of what data is present in Websocket at that time?

Please share your ideas on how to handle this case that is how to find out whats the reason for findout the WebSocket?

Solution 1

The Jetty developers HIGHLY recommend upgrading to Jetty 9 when working with WebSockets. (Disclosure, I'm a Jetty committer)

Jetty 7 and 8 implemented early versions of WebSocket Drafts, and depending on your browser you will get vastly different behavior of WebSocket.

Browsers with pre-final support for websocket (which Jetty 7 and 8 will work with)

• Safari 5.x (or earlier)
• Opera 12.x (or earlier)
• Opera Mini (all versions)
• Chrome 13.x (or earlier)
• Firefox 10.x (or earlier)
• IE 9.x (or earlier)
• Android Browser (any version)
• Blackberry Browser (versions before 10.x)
• Any of the existing Shockwave / Flash WebSocket bridges.

Starting with Jetty 9, all support for Draft versions of WebSocket has been dropped in favor of only working with the released RFC-6455 spec version.

Now, to your 1006 Close Code issue.

That is a local side only close status code, that originates and is reported by Chrome. Depending on your version of Chrome, the reasons for your error 1006 could be of a dozen different reasons. Nearly all of which boil down to either connection or protocol issues.

With Jetty 7 and 8, there are many different timeouts and idle checks (some at the connector, some at the Endpoint layer, some at the Connection layer, even some in the HTTP layer, and yet more in the WebSocket layers) that can get in your way and terminate, harshly, the connection without having WebSocket close handshake occur.

This has been addressed in Jetty 9. There are 2 timeouts, handshake and idle.

If the problem is protocol related, then you can see error code 1006 Abnormal/non-clean termination (local side only), or a 1002 Protocol Violation.

At this point, you can either upgrade to Jetty 9, with better protocol, timeout, connection, close, and error notifications. Or you can turn on all of the debugging on the server side Jetty 7/8 and hope you see a StackTrace indicating the cause of the issue on the server side.

Solution 2

1006 is abnormal termination. Sometimes you will get this with a message "Incomplete Handshake Response". You can use TCP Mon or Wireshark to monitor the socket traffic and look at the headers that are being transmitted.

I've also seen this if the server isn't set up to receive large data on the connection. You'll see something like "connection closed, status=1006, Reason=EOF". Jetty limits the size of the message that can be received by the server. If you try to send a message larger than this size, Jetty will close the connection. You can increase the message size limit on a connection using the setMaxBinaryMessageSize and setMaxTextMessageSize of the Connection object. http://download.eclipse.org/jetty/stable-7/apidocs/org/eclipse/jetty/websocket/WebSocket.Connection.html

Hope this helps.

Comments

[Joakim Erdfelt]

1006 is a local side close code. it MUST NOT be sent in a WebSocket Close control frame by any endpoint. See RFC-6455 Section 7.4.1

[Sanjeev]

I kept seeing 1006 on our client side and server side connections when I tried to send large data messages from a jetty-8 client to a jetty-9 server. Fixed it by increasing the max message size on the server.

[Joakim Erdfelt]

Jetty 9 server would respond with Status Code 1009 (Message too big) in that scenario.

[Sanjeev]

That is how I was finally able to figure out what was going on. (1009)

[vikingsteve]

Problem for me was no SSL factory set up.