Why does grails websockets connection fail but continue to receive messages that have been subscribed to in the browser while using an AWS ELB? - amazon-web-services

Question

Using Grails 2.5.5 with the spring-websockets plugin 1.3.1 and tomcat 8.0.37.
While using an AWS Elastic Load Balancer, the following error is shown in the Javascript console when loading the application in the browser
WebSocket connection to 'ws://...s.com/Application/stomp/059/uyqk9cdn/websocket' failed: Error during WebSocket handshake: Unexpected response code: 400
From research it has been found that the ELB doesn't support websockets and proxying within the ELB, a third party load balancer or potentially using a new Application Load Balancer (the applications are not in a VPC so this is not an easy solution) might be required.
However, after the error, the following logging is received:
Web Socket Opened...
>>> CONNECT
accept-version:1.1,1.0
heart-beat:10000,10000
<<< CONNECTED
version:1.1
heart-beat:0,0
user-name:admin
connected to server undefined
>>> SUBSCRIBE
id:sub-0
destination:/topic/someTopic
Messages are then received by the client fine when they are broadcast
<<< MESSAGE
destination:/topic/someTopic
content-type:application/json;charset=UTF-8
subscription:sub-0
message-id:xb71g__u-16
content-length:89
The code to initiate the websocket connection is
<r:require module="spring-websocket"/>
<r:script>
var socket = new SockJS("${createLink(uri: '/stomp')}");
var client = Stomp.over(socket);
client.connect({}, function () {
var topic = "/topic/digTicketUpdated";
console.log("Subscribing to -> " + topic);
client.subscribe(topic, function (message) {
console.log("Push Message Received From Server");
updateStatus(message.body);
});
});
</r:script>
This is taken from the grails-spring-websocket github page.
Is it possible to figure out if this is fallback that has kicked in, the websocket actually working or some other scenario. To summarise :
Is the websocket falling back to another protocol?
Is there any way to get rid of the 400 error?

Answer 1

Thanks to the suggestions in the comments, it was found that after the "Unexpected response code: 400" was thrown, SockJS attempted to use a long POST XHR request to emulate the web socket and it worked. This was viewable in the Network tab of Chrome Developer Tools as "xhr_streaming".
To prevent the 400 error showing in the development console, a configurable switch was implemented so web socket connections are not attempted when it is known they are not supported, such as on an AWS ELB. This was achieved by passing by removing "websocket" from the allowed protocols when instantiating SockJS :
var allowedProtocols = ['xdr-streaming', 'xhr-streaming', 'iframe-eventsource', 'iframe-htmlfile', 'xdr-polling', 'xhr-polling', 'iframe-xhr-polling', 'jsonp-polling']
var socket = new SockJS(uri, {}, {protocols_whitelist : allowedProtocols});
var client = Stomp.over(socket);