Connection closed before receiving a handshake response
Closed this issue · 7 comments
I'm not sure this is a firehose problem, but I figured you may point me to the right direction. I get the following error:
WebSocket connection to 'ws://domain.com/firehose.json?last_message_sequence=' failed: Connection closed before receiving a handshake response
Looking at the source for the consumer, I can see that the comment said "probably firewall." The server is able to receive the response:
[2014-05-02 08:42:34.373 #10371] DEBUG : HTTP GET with last_sequence 0 for path /firehose.json with query "_=1399019839967" and params {"_"=>"1399019839967"}
[2014-05-02 08:42:34.373 #10371] DEBUG : exec returned: `` and `[]`
[2014-05-02 08:42:34.373 #10371] DEBUG : No message available yet, subscribing. sequence: `0`
I'm not sure why the client disconnects immediately after.
Thanks for your help!
When the browser console is not open, things work as expected. I suppose Chrome takes errors more seriously when the console is open.
Looking at the code a bit closer (admittedly I'm not primarily a JS developer), it looks like Chrome supports WebSockets, but soon dies because of some unknown reason. Long polling is then supposed to kick in, but because the console is open, it never does.
What do you think about being more forgiving to browsers when the console is open?
@config.failed
could be:
@config.failed ||= ->
if console?
console.log "Could not connect"
else
throw "Could not connect"
Do you have firehose behind a load balancer or firewall? I've only run into these types of issues under those circumstances.
Also, could you post your Gemfile.lock? Curious what versions of rainbows/thin and Faye you're running.
@bradgessler thanks for getting back to me. I'm not running it behind a firewall. It's on a vagrant machine that a browser on my host is connecting to. Just to rule out the possibility of vagrant interfering, I started the firehose server on the host machine as well. Same thing.
I'm using Ruby 2.1.1 with this Gemfile.lock
:
GEM
remote: https://rubygems.org/
specs:
addressable (2.3.6)
capistrano (3.2.1)
i18n
rake (>= 10.0.0)
sshkit (~> 1.3)
cookiejar (0.3.2)
dotenv (0.7.0)
em-hiredis (0.2.1)
hiredis (~> 0.4.0)
em-http-request (1.1.2)
addressable (>= 2.3.4)
cookiejar
em-socksify (>= 0.3)
eventmachine (>= 1.0.3)
http_parser.rb (>= 0.6.0)
em-socksify (0.3.0)
eventmachine (>= 1.0.0.beta.4)
eventmachine (1.0.3)
faraday (0.9.0)
multipart-post (>= 1.2, < 3)
faye-websocket (0.7.3)
eventmachine (>= 0.12.0)
websocket-driver (>= 0.3.1)
firehose (1.2.11)
em-hiredis (>= 0.2.0)
em-http-request (>= 1.0.0)
eventmachine (>= 1.0.0)
faraday
faye-websocket
json
rack (~> 1.4.0)
thor
foreman (0.66.0)
dotenv (~> 0.7.0)
thor (~> 0.19.1)
hike (1.2.3)
hiredis (0.4.5)
http_parser.rb (0.6.0)
i18n (0.6.9)
json (1.8.1)
kgio (2.9.2)
multi_json (1.9.3)
multipart-post (2.0.0)
net-scp (1.2.1)
net-ssh (>= 2.6.5)
net-ssh (2.9.0)
rack (1.4.5)
rainbows (4.6.1)
kgio (~> 2.5)
rack (~> 1.1)
unicorn (~> 4.8)
raindrops (0.13.0)
rake (10.3.1)
sprockets (2.12.1)
hike (~> 1.2)
multi_json (~> 1.0)
rack (~> 1.0)
tilt (~> 1.1, != 1.3.0)
sshkit (1.4.0)
net-scp (>= 1.1.2)
net-ssh (>= 2.8.0)
term-ansicolor
term-ansicolor (1.3.0)
tins (~> 1.0)
thor (0.19.1)
tilt (1.4.1)
tins (1.1.0)
unicorn (4.8.2)
kgio (~> 2.6)
rack
raindrops (~> 0.7)
websocket-driver (0.3.3)
PLATFORMS
ruby
DEPENDENCIES
capistrano
firehose (~> 1.2)
foreman
rainbows
sprockets (~> 2.11)
@bradgessler does anything stand out? If not, I should probably close this issue.
Yeah, bump Rainbows down to 4.3.x. There are comparability issues between Faye WebSockets, EM, and newer versions of Rainbows that you'll see in other PRs in this project.
Thanks @bradgessler!
Yep, you can follow that issue at https://github.com/polleverywhere/firehose/issues/22