11
votes

I started running into tons of these errors today:

Net::ReadTimeout (Net::ReadTimeout)
      /usr/local/rvm/rubies/ruby-2.0.0-p0/lib/ruby/2.0.0/net/protocol.rb:158:in `rescue in rbuf_fill'
      /usr/local/rvm/rubies/ruby-2.0.0-p0/lib/ruby/2.0.0/net/protocol.rb:152:in `rbuf_fill'
      /usr/local/rvm/rubies/ruby-2.0.0-p0/lib/ruby/2.0.0/net/protocol.rb:134:in `readuntil'
      /usr/local/rvm/rubies/ruby-2.0.0-p0/lib/ruby/2.0.0/net/protocol.rb:144:in `readline'
      /usr/local/rvm/rubies/ruby-2.0.0-p0/lib/ruby/2.0.0/net/http/response.rb:39:in `read_status_line'
      /usr/local/rvm/rubies/ruby-2.0.0-p0/lib/ruby/2.0.0/net/http/response.rb:28:in `read_new'
      /usr/local/rvm/rubies/ruby-2.0.0-p0/lib/ruby/2.0.0/net/http.rb:1405:in `block in transport_request'
      /usr/local/rvm/rubies/ruby-2.0.0-p0/lib/ruby/2.0.0/net/http.rb:1402:in `catch'
      /usr/local/rvm/rubies/ruby-2.0.0-p0/lib/ruby/2.0.0/net/http.rb:1402:in `transport_request'
      /usr/local/rvm/rubies/ruby-2.0.0-p0/lib/ruby/2.0.0/net/http.rb:1375:in `request'
      /usr/local/rvm/rubies/ruby-2.0.0-p0/lib/ruby/2.0.0/net/http.rb:1368:in `block in request'
      /usr/local/rvm/rubies/ruby-2.0.0-p0/lib/ruby/2.0.0/net/http.rb:851:in `start'
      /usr/local/rvm/rubies/ruby-2.0.0-p0/lib/ruby/2.0.0/net/http.rb:1366:in `request'

I'm running headless (via headless gem) Watir-WebDriver cukes on Firefox 21, Ubuntu server. Here's the active bundle of gems:

Gems included by the bundle:
  * builder (3.2.2)
  * bundler (1.3.5)
  * childprocess (0.3.9)
  * cucumber (1.3.2)
  * cwtestgen (0.1.6)
  * data_magic (0.14)
  * diff-lcs (1.2.4)
  * faker (1.1.2)
  * ffi (1.8.1)
  * gherkin (2.12.0)
  * headless (1.0.1)
  * i18n (0.6.4)
  * multi_json (1.7.5)
  * page-object (0.8.10)
  * page_navigation (0.9)
  * require_all (1.2.1)
  * rspec (2.13.0)
  * rspec-core (2.13.1)
  * rspec-expectations (2.13.0)
  * rspec-mocks (2.13.1)
  * rubyzip (0.9.9)
  * selenium-webdriver (2.33.0)
  * syntax (1.0.0)
  * thor (0.18.1)
  * watir-webdriver (0.6.4)
  * watir-webdriver-performance (0.2.2)
  * websocket (1.0.7)
  * yml_reader (0.2)

I don't even know where to begin resolving this issue. The timeouts are random. They do not occur when I run these tests on Firefox 21 on OS X (not headless). Has anyone experienced this before? ANY and ALL ideas much appreciated -- thank you!

2
I never figured out the cause of this issue, but eventually it went away. I haven't seen this error in over a few days now. Next time I see it I'll work with our sysadmin to try to suss it out and, if we find the root of the problem, I will update this thread.jonsie_araki
Hey, have you found any reason for this yet? I'm running into the same issue.user1120134
Ive had this problem before. For my problem it was a timeout problem. I was having connection issues with my ISP. After the fix from my ISP they went away. I guess there was static on the line.Duck1337
Try using phantomjs the next time it happens and see if there is a difference bettween the two.Chad Brewbaker
I have seen them aswell... sometimes, no errors for days or even weeks, and all of a sudden: ReadTimeout :( I ended up rescue'ing the Exception :-/mhutter

2 Answers

1
votes

I ran into this problem. I do not know why it happens but I found a solution to it. I just terminate the watir browser and headless, then I retry. The problem is that watir loosed the connection to the browser so it cannot be terminated. I think it is a part of the initial problem. To terminate the watir browser I dump the browser object with YAML then parse the result to find the pid of the emulated browser. After it's done the kill command is send to the right pid. Finally the browser and headless are reinitialized.

tryLeft = 3
begin
  @watir.goto url
rescue => error
  tryLeft -= 1

  if tryLeft >= 0
    sleep 1
    retry
  end

  begin
    Timeout::timeout(2) { @watir.close }
  rescue
    File.open(@tmpDumpFile, 'w') { |file| file << YAML::dump(@watir) }
    `awk '/pid:/ {print $2;}' "#{@tmpDumpFile}" | xargs -rt kill 2>&1`
    FileUtils.rm_f(@tmpDumpFile)
  end

  @headless.stop
  `killall Xvfb 2>&1`

  # Reinitialize @watir / @headless then retry
end
0
votes

I have seen this on someone else's machine, and spent a little bit of time diagnosing it.

In that particular situation, the problem appeared to be some muddle with Ruby version managers, meaning that some gems compiled for an older version of Ruby were being picked up.

We blew away their gemsets, reinstalled the gems, and it all started working reliably again.

This might not be your problem here, but it's worth noting for others. Ruby version management is getting easier nowadays, but it's still far too easy to get things into a muddle.