error! xhr poll error

[ReidandKat]

I am receiving the following error over and over:

connected!
authenticated!
error! xhr poll error
connected!
authenticated!
error! xhr poll error
connected!
authenticated!
error! xhr poll error
connected!
authenticated!
error! xhr poll error
connected!
authenticated!
error! xhr poll error
connected!
authenticated!
error! xhr poll error
connected!
authenticated!
error! xhr poll error

The code I am using is directly copied from the example.

[MattMcNam]

Hey, sorry for the long delay in getting to this.

This seems to be caused when Streamtip's server has a lot of connections, and their own code just ignores the error and tries to reconnect, so that's all I'm going to do.

You may still see multiple connected/authenticated events, but xhr ... won't throw an error now.
I don't think this is a big problem since newTip is the main event to be watching anyway.

[MattMcNam]

This still causes problems actually and I don't like just ignoring it as a 'solution', reopening.

[night]

I made some modifications to our nginx upstream configuration, as I believe some 0 content length responses on socket.io are causing nginx to think an upstream is encountering issues when it isn't. Please let me know if this helps (it appears to have on my end).

[Abrahamic-God]

@night I'm still getting many errors, and am struggling to connect and auth.

After several minutes, I usually connect/auth. However, this usually lasts only a few seconds at most before the xhr poll errors resume.

I'm running on a BuyVM VPS with Ubuntu 14.04 and Node.js 0.12.2.

[night]

I cannot reproduce that, unfortunately. I've tested this locally with node 0.12.0. I also tested this on a BuyVM VPS running Debian 7 with node 0.10.38, and did not encounter this issue. I think there's something funky going on with your connection. Can you "curl -vvv https://streamtip.com" and see what's going on? It sounds like you're unable to connect, which I've encountered before when setting the VPS' main IP to be one of their DDoS protected IPs (although in that instance I was having trouble connecting to api.twitch.tv).

[Abrahamic-God]

curl -vvv https://streamtip.com on my BuyVM VPS appears to generate pretty normal output. In those moments where I do get a brief connection to the socket, I can receive notifications and everything works. I can connect, but I can't stay connected.

Curiously, running this code on a DigitalOcean droplet results in far fewer xhr errors. They're still happening, but once every 10-20 seconds or so instead of constantly.

[night]

Is your BuyVM IP 198.98.50.142? If so, nginx is logging your requests as the following:

2015/04/03 22:34:15 [error] 14915#0: *191866 upstream prematurely closed connection while reading response header from upstream, client: 198.98.50.142, server: streamtip.com, request: "GET /socket.io/?client_id=[redacted]&access_token=[redacted]&EIO=3&transport=websocket&sid=j2QNJM8k_ra_3GCaAALW HTTP/1.1", upstream: "http://unix:/var/run/streamtip/streamtip_2.sock:/socket.io/?client_id=[redacted]&access_token=[redacted]&EIO=3&transport=websocket&sid=j2QNJM8k_ra_3GCaAALW", host: "streamtip.com"
2015/04/03 22:34:15 [error] 14915#0: *191866 upstream prematurely closed connection while reading response header from upstream, client: 198.98.50.142, server: streamtip.com, request: "GET /socket.io/?client_id=[redacted]&access_token=[redacted]&EIO=3&transport=websocket&sid=j2QNJM8k_ra_3GCaAALW HTTP/1.1", upstream: "http://unix:/var/run/streamtip/streamtip_3.sock:/socket.io/?client_id=[redacted]&access_token=[redacted]&EIO=3&transport=websocket&sid=j2QNJM8k_ra_3GCaAALW", host: "streamtip.com"
2015/04/03 22:34:15 [error] 14915#0: *191866 upstream prematurely closed connection while reading response header from upstream, client: 198.98.50.142, server: streamtip.com, request: "GET /socket.io/?client_id=[redacted]&access_token=[redacted]&EIO=3&transport=websocket&sid=j2QNJM8k_ra_3GCaAALW HTTP/1.1", upstream: "http://unix:/var/run/streamtip/streamtip_1.sock:/socket.io/?client_id=[redacted]&access_token=[redacted]&EIO=3&transport=websocket&sid=j2QNJM8k_ra_3GCaAALW", host: "streamtip.com"
2015/04/03 22:34:15 [error] 14915#0: *191866 upstream prematurely closed connection while reading response header from upstream, client: 198.98.50.142, server: streamtip.com, request: "GET /socket.io/?client_id=[redacted]&access_token=[redacted]&EIO=3&transport=websocket&sid=j2QNJM8k_ra_3GCaAALW HTTP/1.1", upstream: "http://unix:/var/run/streamtip/streamtip_4.sock:/socket.io/?client_id=[redacted]&access_token=[redacted]&EIO=3&transport=websocket&sid=j2QNJM8k_ra_3GCaAALW", host: "streamtip.com"
2015/04/03 22:34:16 [error] 14918#0: *191922 upstream prematurely closed connection while reading response header from upstream, client: 198.98.50.142, server: streamtip.com, request: "GET /socket.io/?client_id=[redacted]&access_token=[redacted]&EIO=3&transport=websocket&sid=v9075e4pIYSlDLEcAALX HTTP/1.1", upstream: "http://unix:/var/run/streamtip/streamtip_2.sock:/socket.io/?client_id=[redacted]&access_token=[redacted]&EIO=3&transport=websocket&sid=v9075e4pIYSlDLEcAALX", host: "streamtip.com"
2015/04/03 22:34:16 [error] 14918#0: *191922 upstream prematurely closed connection while reading response header from upstream, client: 198.98.50.142, server: streamtip.com, request: "GET /socket.io/?client_id=[redacted]&access_token=[redacted]&EIO=3&transport=websocket&sid=v9075e4pIYSlDLEcAALX HTTP/1.1", upstream: "http://unix:/var/run/streamtip/streamtip_3.sock:/socket.io/?client_id=[redacted]&access_token=[redacted]&EIO=3&transport=websocket&sid=v9075e4pIYSlDLEcAALX", host: "streamtip.com"
2015/04/03 22:34:16 [error] 14918#0: *191922 upstream prematurely closed connection while reading response header from upstream, client: 198.98.50.142, server: streamtip.com, request: "GET /socket.io/?client_id=[redacted]&access_token=[redacted]&EIO=3&transport=websocket&sid=v9075e4pIYSlDLEcAALX HTTP/1.1", upstream: "http://unix:/var/run/streamtip/streamtip_1.sock:/socket.io/?client_id=[redacted]&access_token=[redacted]&EIO=3&transport=websocket&sid=v9075e4pIYSlDLEcAALX", host: "streamtip.com"
2015/04/03 22:34:16 [error] 14918#0: *191922 upstream prematurely closed connection while reading response header from upstream, client: 198.98.50.142, server: streamtip.com, request: "GET /socket.io/?client_id=[redacted]&access_token=[redacted]&EIO=3&transport=websocket&sid=v9075e

I'm not sure why your requests are resulting in this error, so it will probably require more debugging.

[Abrahamic-God]

That is indeed my BuyVM IP.

[night]

I'm curious if there is a misconfiguration on your end, since every failing request is only websockets. Is there something on your end blocking websockets? Websockets require HTTP 1.1, so if your client or something in between doesn't support that, it could be why it's failing.

[night]

What changes if you enable multiplexing and modify your transports like the following:

        transports: [
            'xhr-polling', 
            'jsonp-polling', 
            'polling'
        ],

[Abrahamic-God]

There shouldn't be much room for misconfiguration. This BuyVM VPS is pretty bare. It's got node installed and I'm running NodeCG via PM2. Nothing else. NodeCG itself also uses Socket.IO for all its communication and that does not have issues. I can try wiping the VPS and starting fresh if you think it's a worthwhile route of investigation.

Enabling multiplexing and modifying my transports did not seem to make a difference. Curiously, even if I removed xhr-polling from the list I still got the exact same xhr error.

[night]

If you're only testing in an environment with nodecg running, perhaps you should isolate with just this package.

Additionally, client logs would be helpful. Debug instructions are here: http://socket.io/docs/logging-and-debugging/

You can debug like:

DEBUG=* node testing.js

[Abrahamic-God]

You're right, step one should have been isolating to just this package and trying that. Not sure why I didn't have the presence of mind to do that.

Unfortunately, I'm getting the same error. Here's a gist with the debug output from a few seconds of script execution time: https://gist.github.com/Lange/cd70db7f1588096b68d2

[night]

Are you sure the correct version of socket.io is being loaded? Sometimes if you have a package in ~/node_modules node will prefer that over the node_modules in the app dir.

[Abrahamic-God]

There is no node_modules folder in any parent directory of the test script I was running. The version of socket.io-client being loaded is the one specified in this package's package.json, 1.3.5.

[night]

The socket.io in use by Streamtip is lower, 1.2.1

[Abrahamic-God]

Manually installing socket.io-client@1.2.1 does not seem to have resolved the error. Additionally, I tried removing the seemingly accidental events dependency (events is a core module) from this package's package.json, but this too had no apparent effect.

[night]

It's unfortunate, but I couldn't tell you why you're having issues connecting. Maybe try downgrading from node 0.12.x to 0.10.x, or trying a different server completely. I've tried your client id and access token, and haven't been able to reproduce any issues over at BuyVM or locally.

[MattMcNam]

I've seen the error a handful of times locally and once on my vps (81.4.106.145 if it helps, all subsequent tests connected first try), but it's usually just shown once, socket reconnects, everything's fine, not continued errors.

[Abrahamic-God]

I tested on 0.10.38 on my BuyVM VPS this morning, no luck.

I'm doing more tests on another DigitalOcean droplet and I'm having very few, if any, xhr poll errors. I think I'll spin up a fresh droplet for the project that I want to use StreamTip for and see if it works.

[night]

@MattMcNam Those dropped connections should be what I resolved earlier, as nginx was failing over an upstream if it returned a 5xx error (by default max_fails is set to 1 apparently). Please let me know if you are still seeing this issue often. Seeing it once in a while is normal, as sometimes updates are pushed or an uncaught error occurs (like in net calls in PayPal's sdk, for example) and requires node instances to restart.

@lange I still have a good belief there's something funky going on with the connection, somewhere. Either the protocol isn't being sent properly or for some reason a websocket cannot be established. I read over the source code that returns a "transport error," and seems to only happen when there's a socket error. Maybe you can try experimenting with what you connect to.

Change "https://streamtip.com" to the following:

http://streamtip.com
http://107.161.180.203
http://198.251.81.112
http://172.16.16.98 (BuyVM internal IP in NJ)

[Abrahamic-God]

Interesting results:

https://streamtip.com/	❌
http://streamtip.com/	❌
http://107.161.180.203/	✅
http://198.251.81.112/	✅
http://172.16.16.98/	✅

All the entries with a checkmark connected immediately and didn't show any xhr errors during the time I observed them, which was about 60 seconds each.

[night]

This definitely seems like a configuration issue somewhere, as the IP addresses provided point to the two nodes Streamtip uses. I'm curious if there's some sort of reverse proxy (or something similar) empoyed that doesn't support the websocket connection and is causing it to be blocked. You might also check that the DNS is resolving properly to the listed IPs. There's definitely something wrong, but I don't believe it's an issue on Streamtip's end (as I can't seem to reproduce this).

[Abrahamic-God]

My VPS appears to be able to correctly resolve the address of streamtip.com, so perhaps we can use that as a workaround in the library.

@MattMcNam, would it be a good idea to have streamtip-listener resolve the IP of streamtip.com on startup and connect the socket to the IP directly?

[night]

Since this seems like a socket.io-client library issue, I'm not sure working around a bug is a good idea. Perhaps if you can reproduce the conditions needed to make this occur, then it could potentially be traced and fixed. Were you able to reproduce this on DigitalOcean? What about another virtual machine (or the same reinstalled) at BuyVM?

This appears to be the same issue: socketio/socket.io#1942