firehoseio/firehose

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.