SockJS websocket timeout on Websphere

Hello,

We have a very interesting problem in the Websocket communication which depends on whether we use SockJS or not. Our application uses Websocket protocol for communication between the backend and frontend. In the backend side we use Spring Websocket with SockJS registry.addEndpoint("/ws") .withSockJS() .setClientLibraryUrl("https://cdn.jsdelivr.net/sockjs/1.1.0/sockjs.min.js");

In the frontend app we use a Stomp protocol over SockJS. var socket = new SockJS(backendUrl + '/ws'); stompClient = Stomp.over(socket);

We had ran our backend application on Tomcat and the frontend application on Websphere Application Server (with IHS in front of it. The IBM HTTP Server is Apache HTTP Server under the hood). In this scenario, all the Websocket communication ran smoothly and without issues. Afterwards, we got a requirement to move our backend application on Websphere Application Server (version 9, which supports Websockets). In front of the WAS, we also have IHS. Here, we found a problem - the SockJS websocket communication times out and SockJS switches to XHR. In the SockJS logs, we get this message: _sockjs-client:browser:xhr cleanup +2ms browser.js:120 sockjs-client:main transportTimeout +8s browser.js:120 sockjs-client:main transportClose +0ms undefined 2007 Transport timed out

In the /websocket request, we have the following headers: Accept-Encoding:gzip, deflate, sdch, br Accept-Language:en-US,en;q=0.8,bg;q=0.6 Cache-Control:no-cache Connection:Upgrade Cookie: {some cookies} Host:{backend host} Origin:{frontend host} Pragma:no-cache Sec-WebSocket-Extensions:permessage-deflate; client_max_window_bits Sec-WebSocket-Key:krf8DAkLQhO3mJJpKuRF9A== Sec-WebSocket-Version:13 Upgrade:websocket User-Agent:Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/54.0.2840.99 Safari/537.36

And in the response: Access-Control-Allow-Credentials:true Access-Control-Allow-Origin:{frontend host} Connection:Upgrade Content-Language:en-US Content-Length:0 Date:Wed, 23 Nov 2016 06:26:16 GMT Sec-WebSocket-Accept:VarVcM0dY/2koYDQ3G3rpy6XMYo= Strict-Transport-Security:max-age=31536000; includeSubDomains; preload Upgrade:websocket Vary:Origin X-Content-Type-Options:nosniff X-Powered-By:Servlet/3.1 X-XSS-Protection:1; mode=block

The most interesting part of the problem is that when we turn off SockJS - the websockets run normally. We are fighting with this problem in the last two weeks and really don’t know how to continue. Every tip or help will be highly appreciated.

Thank you, Zahari

[nlebas]

I’ve encountered a similar issue and in my case, it is not related to the server side of the websocket, but with the network load.

In most cases everything works fine, but sometimes hell breaks loose. Here is the sequence of events:

• the website loads and fires a bunch of HTTP requests.
• new SockJS(url)
• the info request flies by quickly (~3ms)
• the websocket request fires, but it is stuck for 5 seconds for some reason, probably the limit of concurrent connections per website stands in the way.
• before the browser comes around to actually sending out the websocket request, SockJS’ timeout expires and closes it.
• the server receives and accepts the request but finds the websocket already closed.
• SockJS moves on to try out other protocols if they are enabled (I disabled them in my case)

Workaround for me I’ve disabled SockJS’ internal timeout with:

var sockJSConn = new SockJS(url);
sockJSConn._transportTimeout = function() { console.log('gotcha!!!'); };

Works for me so far, but it feels a bit like trespassing.

Hope this helps,

[github-actions[bot]]

This issue has been inactive for 30 days. It will be in closed in 5 days without any new activity.