SockJS support flakey

[dhm116]

I've been running into a lot of issues using the event bridge with IE (7,8,9) clients, which simply get disconnected after about 8 seconds regardless of whether any data is exchanged with the server. I've been able to reproduce this issue in Chrome (latest stable) by using transports other than the websocket default.

I'm running vertx 1.3.0 and I've tested against sockjs 0.2.1 and 0.3.0 with equal results.

If I run any of the sockjs smoke tests, they all (well, supported transports at least) work fine on IE and Chrome.

XHR-streaming is the default transport picked by the cursors or smoke tests for IE, which works perfectly fine, however XHR-streaming does not work in vert.x and results in the connection being immediately disconnected.

Any thoughts?

[purplefox]

I run all the sockjs unit tests and protocol tests against Vert.x for each release and they all pass. I believe this contains tests for xhr-streaming too.

I'm a bit confused with your last comment "XHR-streaming is the default transport picked by the cursors or smoke tests for IE, which works perfectly fine, however XHR-streaming does not work in vert.x ". You're saying xhr-streaming works fine, but does not work? Can you clarify? It seems a little ambiguous.

[dhm116]

Yes, the unit tests and protocol tests from the sockjs.org site work fine on IE 7,8,9 with no issues of premature disconnections. When I create an instance of vertx.web-server-v1.0 with bridge enabled and connect with IE, depending on which transport I select in the whitelist for sockjs, it will either immediately disconnect or disconnect after about 8 seconds. If I select something like jsonp, even Chrome disconnects. I'm not sure this is something you could notice with a unit test since it does not immediately disconnect with XHR.

So, basically what I'm saying is that Sockjs appears to be working fine, but something about the server-side implementation seems to be causing issues with IE (with any protocol) and at least Chrome with certain transports. I can try to do some more thorough analysis of each protocol and the issues I'm seeing, but I'm testing this on multiple client machines, so it's not isolated to my particular desktop.

Thanks for any help btw!

[purplefox]

I still don't follow - you say you've run the unit tests against Vert.x, and they all pass? Or are you running them against the SockJS node.js server implementation? Please clarify

[dhm116]

They pass against the SockJS node.js implementation

[purplefox]

They also passed against the Vert.x server implementation of SockJS when I released 1.3.0.final - I run them as part of the release process.

Can you put together a step by step of how to replicate this issue using Vert.x?

[dhm116]

Yeah it's pretty easy to replicate - the vert.x SockJS example doesn't work in IE7,8,9 because it doesn't support websockets.

The vert.x eventbusbridge example exhibits the exact issue - if you use IE7,8,9 and connect, within about 8 seconds it willl disconnect. You can still send messages within that timeframe, but it can't maintain a persistent connection.

[dhm116]

I originally thought it might be an issue with how SockJS binds to window.beforeunload (sockjs/sockjs-client#90), but that's resolved in v0.3.0 and I still experienced the same issues using that library instead of 0.2.1.

[purplefox]

Have you tried this with master?

[purplefox]

Investigating further

[purplefox]

I've tried this with IE9 and latest sockjs version and I can replicate this issue.

(BTW I have fixed one issue in vertxbus.js in which the options weren't being passed through to the sockjs constructor properly (I suspect sockjs changed it's api somewhere along the line), this meant any protocol whitelist was ignored. This is fixed in master)

When specifying a whitelist of xhr-streaming I have noticed that sockjs in IE does not attempt to use that protocol. You can easily see this by running the server in master with trace enabled and seeing what requests reach the server.

I therefore suspect there is some bug in the sockjs client when running in IE. I recommend playing around with whitelist a bit and seeing what requests hit the server and posting something on the sockjs list.

[purplefox]

A bit more on this:

It seems that xhr-streaming is not supported on IE - the streaming protocol that is supported is iframe-htmlfile.

If you set protocols_whitelist to contain only ' iframe-htmlfile' then IE will attempt to use that protocol.

What then happens is the connection stays alive until session_timeout is reached (default 5 seconds) at which point Vert.x will close the connection.

When the sockjs client notices the connection has been closed it will open another one the next time a message is sent.

This appears to work the first time, but when Vert.x closes the 2nd connection, for some reason the client doesn't attempt to re-open another one.

AIUI the correct behaviour on the server is to close the connection after session timeout, but with SockJS is always hard to tell since they don't provide a spec :(

I suggest posting a message on the SockJS group to figure out what the correct behaviour should be.

[purplefox]

Also... this issue is not IE specific, chrome does the exact same thing with iframe-html.

[purplefox]

https://groups.google.com/forum/?fromgroups=#!topic/sockjs/8b7Pj69WBN4

[purplefox]

I've added a fix in master. Can you verify it works ok for you?

[dhm116]

Sure thing - I'll keep you posted. Thanks a ton for looking into this, I had no idea it would spark the massive discussion over on the sockjs forum.

[dhm116]

So far, it appears to have done the trick. I'll close this for now. I really appreciate your help and quick turnaround time!

[purplefox]

No problem :)