Hanging connections with SockJS when using xhr-streaming

702 views
Skip to first unread message

dubois.se...@gmail.com

unread,
Jan 10, 2014, 2:53:37 PM1/10/14
to soc...@googlegroups.com

Hi,

  We are using STOMP over SockJS to connect client browsers to a RabbitMQ server that uses Web-stomp plugin (which itself embeds a SockJS server).

  What we noticed is that when using a non websocket-capable browser (namely IE9), the SockJS connections are not closed properly, which causes potentially very serious connection leaks in the RabbitMQ broker.  We were able to track it down to the fallback protocol used by SockJS.  When we leave the default value, SockJS falls back to xhr-streaming and then does not close the connection properly upon client shutdown.  When we force it to use polling e.g. if we specify "xhr-polling" in the protocol whitelist when creating the client SockJS socket instance, then the connections are closed properly.

  Our setup is fairly simple the Client browser connects directly to the SockJS server that runs within the RabbitMQ webstomp plugin.  Nothing fancy here.  We were able to reproduce the problem using IE9, Firefox and Chrome by forcing it to use xhr-streaming.  

  Websocket-capable browsers (e.g. FF, Chrome, IE10+) work fine by default when using the native websockets .

  We are using sockJS version 0.3.4

  Included is a file of SockJS traces of the client shutdown using xhr-streaming, websocket and xhr-polling respectively.

  Has anybody encountered this problem?  If so is there any solution to this?

Thanks and BR,
/Sebastien


sockJs_close_trace.log
Reply all
Reply to author
Forward
0 new messages