When I click this label:
<label> Row </label>
using this Watir code
br.frame(:name, "frameset").frame(:name, "main_content").span(:class=>"tabtext", :text=>/Row/).click
a new browser window opens, but I get this error message:
Timeout::Error: Timeout::Error
from /Users/zeljko/.rvm/rubies/ruby-1.9.3-p0/lib/ruby/1.9.1/net/protocol.rb:146:in `rescue in rbuf_fill'
from /Users/zeljko/.rvm/rubies/ruby-1.9.3-p0/lib/ruby/1.9.1/net/protocol.rb:140:in `rbuf_fill'
from /Users/zeljko/.rvm/rubies/ruby-1.9.3-p0/lib/ruby/1.9.1/net/protocol.rb:122:in `readuntil'
from /Users/zeljko/.rvm/rubies/ruby-1.9.3-p0/lib/ruby/1.9.1/net/protocol.rb:132:in `readline'
from /Users/zeljko/.rvm/rubies/ruby-1.9.3-p0/lib/ruby/1.9.1/net/http.rb:2562:in `read_status_line'
from /Users/zeljko/.rvm/rubies/ruby-1.9.3-p0/lib/ruby/1.9.1/net/http.rb:2551:in `read_new'
from /Users/zeljko/.rvm/rubies/ruby-1.9.3-p0/lib/ruby/1.9.1/net/http.rb:1319:in `block in transport_request'
from /Users/zeljko/.rvm/rubies/ruby-1.9.3-p0/lib/ruby/1.9.1/net/http.rb:1316:in `catch'
from /Users/zeljko/.rvm/rubies/ruby-1.9.3-p0/lib/ruby/1.9.1/net/http.rb:1316:in `transport_request'
from /Users/zeljko/.rvm/rubies/ruby-1.9.3-p0/lib/ruby/1.9.1/net/http.rb:1293:in `request'
from /Users/zeljko/.rvm/rubies/ruby-1.9.3-p0/lib/ruby/1.9.1/net/http.rb:1286:in `block in request'
from /Users/zeljko/.rvm/rubies/ruby-1.9.3-p0/lib/ruby/1.9.1/net/http.rb:745:in `start'
from /Users/zeljko/.rvm/rubies/ruby-1.9.3-p0/lib/ruby/1.9.1/net/http.rb:1284:in `request'
from /Users/zeljko/.rvm/gems/ruby-1.9.3-p0/gems/selenium-webdriver-2.19.0/lib/selenium/webdriver/remote/http/default.rb:81:in `response_for'
from /Users/zeljko/.rvm/gems/ruby-1.9.3-p0/gems/selenium-webdriver-2.19.0/lib/selenium/webdriver/remote/http/default.rb:43:in `request'
from /Users/zeljko/.rvm/gems/ruby-1.9.3-p0/gems/selenium-webdriver-2.19.0/lib/selenium/webdriver/remote/http/common.rb:40:in `call'
from /Users/zeljko/.rvm/gems/ruby-1.9.3-p0/gems/selenium-webdriver-2.19.0/lib/selenium/webdriver/remote/bridge.rb:590:in `raw_execute'
from /Users/zeljko/.rvm/gems/ruby-1.9.3-p0/gems/selenium-webdriver-2.19.0/lib/selenium/webdriver/remote/bridge.rb:568:in `execute'
from /Users/zeljko/.rvm/gems/ruby-1.9.3-p0/gems/selenium-webdriver-2.19.0/lib/selenium/webdriver/remote/bridge.rb:350:in `clickElement'
from /Users/zeljko/.rvm/gems/ruby-1.9.3-p0/gems/selenium-webdriver-2.19.0/lib/selenium/webdriver/common/element.rb:34:in `click'
from /Users/zeljko/.rvm/gems/ruby-1.9.3-p0/gems/watir-webdriver-0.5.3/lib/watir-webdriver/elements/element.rb:107:in `click'
from (irb):75
from /Users/zeljko/.rvm/rubies/ruby-1.9.3-p0/bin/irb:16:in `<main>'
I do not see anything strange in any browser window. The new window opens pretty quickly. I am not sure why I got the timeout error. Is there something I can do to get rid of it? Or is the page just to slow to respond?
If I rescue the exception I can close the new window and continue with the script, but I would like to avoid rescuing the error.
Environment: Mac OS X 10.7.3, Firefox 10.0.1, ruby 1.9.3p0, selenium-webdriver 2.19.0, watir-webdriver 0.5.3
Update:
I am pretty sure the problem is caused by the window being open by window.showModalDialog. For example, this times out:
b.execute_script "window.showModalDialog('http://google.com');"
I will investigate more and update the question. Looks like Selenium does not have support for window.showModalDialog yet: http://code.google.com/p/selenium/issues/detail?id=284
Since you are clicking a span, which is not something that would normally respond to a click in basic HTML, it makes me suspect there is some kind of javascript code being executed in response perhaps to it seeing an onclick event.
Have you tried using .fire_event('onclick') instead of .click to see if that would still invoke the code that opens the new page but avoids the timeout?
Related
I am using watir-webdriver gem to run over a website.
I tried to click a button to load more content in a webpage, for that I used the following code:
b = Watir::Browser.new
b.goto "https://www.example.com/"
b.button(:class => "ga_Finder_Load_More").click
This code is running fine in linux(ubuntu) and I can load the data in the webpage by clicking the button. But when I run the same code in window 10 I am getting the following error,
C:/Ruby200/lib/ruby/gems/2.0.0/gems/watir-webdriver-0.9.1/lib/watir-webdriver/elements/element.rb:508:in `assert_exists' from C:/Ruby200/lib/ruby/gems/2.0.0/gems/watir-webdriver-0.9.1/lib/watir-webdriver/elements/element.rb:114:in `click' from leafly_v1.3.rb:70:in `block (2 levels) in <main>' from leafly_v1.3.rb:67:in `each' from leafly_v1.3.rb:67:in `block in <main>' from C:/Ruby200/lib/ruby/gems/2.0.0/gems/nokogiri-1.6.6.4-x86-mingw32/lib/nokogiri/xml/node_set.rb:187:in `block in each' from C:/Ruby200/lib/ruby/gems/2.0.0/gems/nokogiri-1.6.6.4-x86-mingw32/lib/nokogiri/xml/node_set.rb:186:in `upto' from C:/Ruby200/lib/ruby/gems/2.0.0/gems/nokogiri-1.6.6.4-x86-mingw32/lib/nokogiri/xml/node_set.rb:186:in `each' from leafly_v1.3.rb:62:in `<main>' C:\Ruby200>
Ruby version - 2.0.0
watir-webdriver - 0.9.1
Can anyone please help me to fix this or can any one suggest me alternate method to click a button.
Thanks.
It often happens between different operating systems and browsers that pages will load with slightly different timing. Try:
b.button(:class => "ga_Finder_Load_More").when_present.click
I'm using Rails and Rollbar to track errors and Resque to handle delayed tasks. One of my workers is failing with below error in the resque GUI:
Net::ReadTimeout
/app/vendor/ruby-2.0.0/lib/ruby/2.0.0/net/protocol.rb:158:in `rescue in rbuf_fill'
/app/vendor/ruby-2.0.0/lib/ruby/2.0.0/net/protocol.rb:152:in `rbuf_fill'
/app/vendor/ruby-2.0.0/lib/ruby/2.0.0/net/protocol.rb:134:in `readuntil'
/app/vendor/ruby-2.0.0/lib/ruby/2.0.0/net/protocol.rb:144:in `readline'
/app/vendor/ruby-2.0.0/lib/ruby/2.0.0/net/http/response.rb:39:in `read_status_line'
/app/vendor/ruby-2.0.0/lib/ruby/2.0.0/net/http/response.rb:28:in `read_new'
/app/vendor/ruby-2.0.0/lib/ruby/2.0.0/net/http.rb:1412:in `block in transport_request'
/app/vendor/ruby-2.0.0/lib/ruby/2.0.0/net/http.rb:1409:in `catch'
/app/vendor/ruby-2.0.0/lib/ruby/2.0.0/net/http.rb:1409:in `transport_request'
/app/vendor/ruby-2.0.0/lib/ruby/2.0.0/net/http.rb:1382:in `request'
/app/vendor/ruby-2.0.0/lib/ruby/2.0.0/net/http.rb:1283:in `request_get'
/app/vendor/ruby-2.0.0/lib/ruby/2.0.0/net/http.rb:479:in `block in get_response'
/app/vendor/ruby-2.0.0/lib/ruby/2.0.0/net/http.rb:852:in `start'
/app/vendor/ruby-2.0.0/lib/ruby/2.0.0/net/http.rb:582:in `start'
/app/vendor/ruby-2.0.0/lib/ruby/2.0.0/net/http.rb:477:in `get_response'
/app/app/services/get_json.rb:4:in `call'
/app/app/models/imdb.rb:9:in `data'
/app/app/models/customer.rb:92:in `imdb_data'
/app/app/models/customer.rb:60:in `get_external_data'
/app/app/models/customer.rb:13:in `scan'
/app/app/models/shop.rb:110:in `block in bulk_scan'
/app/app/models/shop.rb:101:in `each'
/app/app/models/shop.rb:101:in `bulk_scan'
/app/app/workers/bulk_scanner.rb:9:in `perform'
But it would be really helpful to see more robust information about the failure. E.g. what were the parameters. Usually I use Rollbar for this type of thing, but it doesn't seem to be logging this error for some reason.
How would I go about fixing this bug? Because I don't really know what's triggering it? (my worker is basically looping through a whole bunch of API calls with different users, and I don't know which one is failing)
You can create a custom logger, and use it to record useful information to trace your problem. In your worker, add debug statements that dump out variable contents, etc.
my_log = Logger.new("log/worker.log")
def do_stuff
my_log.info "#do_stuff"
end
Another option is to put a breakpoint in your code. You'll get an interactive shell that you can use to fiddle around.
debugger
We are currently upgrading our Rails app to Rails 4. In 3.2, our Cucumber (1.3.17) tests run fine (if lamentably slowly), with Capybara (2.4.4), Poltergeist (1.5.1), and PhantomJS (1.9.8) under the hood.
But in both 4.0.12 and 4.1.8, we get a stream closed (IOError) at a random point in the run:
stream closed (IOError)
/var/lib/jenkins/.rvm/gems/ruby-2.1.5#tallama-integration/gems/cucumber-1.3.17/lib/cucumber/formatter/pretty.rb:156:in `write'
/var/lib/jenkins/.rvm/gems/ruby-2.1.5#tallama-integration/gems/cucumber-1.3.17/lib/cucumber/formatter/pretty.rb:156:in `puts'
/var/lib/jenkins/.rvm/gems/ruby-2.1.5#tallama-integration/gems/cucumber-1.3.17/lib/cucumber/formatter/pretty.rb:156:in `step_name'
/var/lib/jenkins/.rvm/gems/ruby-2.1.5#tallama-integration/gems/cucumber-1.3.17/lib/cucumber/ast/tree_walker.rb:181:in `block in send_to_all'
/var/lib/jenkins/.rvm/gems/ruby-2.1.5#tallama-integration/gems/cucumber-1.3.17/lib/cucumber/ast/tree_walker.rb:179:in `each'
/var/lib/jenkins/.rvm/gems/ruby-2.1.5#tallama-integration/gems/cucumber-1.3.17/lib/cucumber/ast/tree_walker.rb:179:in `send_to_all'
/var/lib/jenkins/.rvm/gems/ruby-2.1.5#tallama-integration/gems/cucumber-1.3.17/lib/cucumber/ast/tree_walker.rb:173:in `broadcast'
/var/lib/jenkins/.rvm/gems/ruby-2.1.5#tallama-integration/gems/cucumber-1.3.17/lib/cucumber/ast/tree_walker.rb:119:in `visit_step_name'
/var/lib/jenkins/.rvm/gems/ruby-2.1.5#tallama-integration/gems/cucumber-1.3.17/lib/cucumber/ast/tree_walker.rb:112:in `block in visit_step_result'
/var/lib/jenkins/.rvm/gems/ruby-2.1.5#tallama-integration/gems/cucumber-1.3.17/lib/cucumber/ast/tree_walker.rb:170:in `broadcast'
/var/lib/jenkins/.rvm/gems/ruby-2.1.5#tallama-integration/gems/cucumber-1.3.17/lib/cucumber/ast/tree_walker.rb:111:in `visit_step_result'
/var/lib/jenkins/.rvm/gems/ruby-2.1.5#tallama-integration/gems/cucumber-1.3.17/lib/cucumber/ast/step_invocation.rb:43:in `visit_step_result'
/var/lib/jenkins/.rvm/gems/ruby-2.1.5#tallama-integration/gems/cucumber-1.3.17/lib/cucumber/ast/step_invocation.rb:39:in `accept'
/var/lib/jenkins/.rvm/gems/ruby-2.1.5#tallama-integration/gems/cucumber-1.3.17/lib/cucumber/ast/tree_walker.rb:106:in `block in visit_step'
/var/lib/jenkins/.rvm/gems/ruby-2.1.5#tallama-integration/gems/cucumber-1.3.17/lib/cucumber/ast/tree_walker.rb:170:in `broadcast'
/var/lib/jenkins/.rvm/gems/ruby-2.1.5#tallama-integration/gems/cucumber-1.3.17/lib/cucumber/ast/tree_walker.rb:105:in `visit_step'
/var/lib/jenkins/.rvm/gems/ruby-2.1.5#tallama-integration/gems/cucumber-1.3.17/lib/cucumber/ast/step_collection.rb:19:in `block in accept'
/var/lib/jenkins/.rvm/gems/ruby-2.1.5#tallama-integration/gems/cucumber-1.3.17/lib/cucumber/ast/step_collection.rb:18:in `each'
/var/lib/jenkins/.rvm/gems/ruby-2.1.5#tallama-integration/gems/cucumber-1.3.17/lib/cucumber/ast/step_collection.rb:18:in `accept'
/var/lib/jenkins/.rvm/gems/ruby-2.1.5#tallama-integration/gems/cucumber-1.3.17/lib/cucumber/ast/tree_walker.rb:100:in `block in visit_steps'
/var/lib/jenkins/.rvm/gems/ruby-2.1.5#tallama-integration/gems/cucumber-1.3.17/lib/cucumber/ast/tree_walker.rb:170:in `broadcast'
/var/lib/jenkins/.rvm/gems/ruby-2.1.5#tallama-integration/gems/cucumber-1.3.17/lib/cucumber/ast/tree_walker.rb:99:in `visit_steps'
/var/lib/jenkins/.rvm/gems/ruby-2.1.5#tallama-integration/gems/cucumber-1.3.17/lib/cucumber/ast/tree_walker.rb:15:in `block in execute'
/var/lib/jenkins/.rvm/gems/ruby-2.1.5#tallama-integration/gems/cucumber-1.3.17/lib/cucumber/runtime.rb:83:in `block (2 levels) in with_hooks'
/var/lib/jenkins/.rvm/gems/ruby-2.1.5#tallama-integration/gems/cucumber-1.3.17/lib/cucumber/runtime.rb:99:in `before_and_after'
/var/lib/jenkins/.rvm/gems/ruby-2.1.5#tallama-integration/gems/cucumber-1.3.17/lib/cucumber/runtime.rb:82:in `block in with_hooks'
/var/lib/jenkins/.rvm/gems/ruby-2.1.5#tallama-integration/gems/cucumber-1.3.17/lib/cucumber/runtime/support_code.rb:120:in `call'
/var/lib/jenkins/.rvm/gems/ruby-2.1.5#tallama-integration/gems/cucumber-1.3.17/lib/cucumber/runtime/support_code.rb:120:in `block (3 levels) in around'
/var/lib/jenkins/.rvm/gems/ruby-2.1.5#tallama-integration/gems/cucumber-1.3.17/lib/cucumber/language_support/language_methods.rb:9:in `block in around'
/var/lib/jenkins/.rvm/gems/ruby-2.1.5#tallama-integration/gems/cucumber-1.3.17/lib/cucumber/language_support/language_methods.rb:97:in `call'
/var/lib/jenkins/.rvm/gems/ruby-2.1.5#tallama-integration/gems/cucumber-1.3.17/lib/cucumber/language_support/language_methods.rb:97:in `execute_around'
/var/lib/jenkins/.rvm/gems/ruby-2.1.5#tallama-integration/gems/cucumber-1.3.17/lib/cucumber/language_support/language_methods.rb:8:in `around'
/var/lib/jenkins/.rvm/gems/ruby-2.1.5#tallama-integration/gems/cucumber-1.3.17/lib/cucumber/runtime/support_code.rb:119:in `block (2 levels) in around'
/var/lib/jenkins/.rvm/gems/ruby-2.1.5#tallama-integration/gems/cucumber-1.3.17/lib/cucumber/runtime/support_code.rb:123:in `call'
/var/lib/jenkins/.rvm/gems/ruby-2.1.5#tallama-integration/gems/cucumber-1.3.17/lib/cucumber/runtime/support_code.rb:123:in `around'
/var/lib/jenkins/.rvm/gems/ruby-2.1.5#tallama-integration/gems/cucumber-1.3.17/lib/cucumber/runtime.rb:94:in `around'
/var/lib/jenkins/.rvm/gems/ruby-2.1.5#tallama-integration/gems/cucumber-1.3.17/lib/cucumber/runtime.rb:81:in `with_hooks'
/var/lib/jenkins/.rvm/gems/ruby-2.1.5#tallama-integration/gems/cucumber-1.3.17/lib/cucumber/ast/tree_walker.rb:13:in `execute'
/var/lib/jenkins/.rvm/gems/ruby-2.1.5#tallama-integration/gems/cucumber-1.3.17/lib/cucumber/ast/scenario.rb:32:in `block in accept'
/var/lib/jenkins/.rvm/gems/ruby-2.1.5#tallama-integration/gems/cucumber-1.3.17/lib/cucumber/ast/scenario.rb:79:in `with_visitor'
/var/lib/jenkins/.rvm/gems/ruby-2.1.5#tallama-integration/gems/cucumber-1.3.17/lib/cucumber/ast/scenario.rb:31:in `accept'
/var/lib/jenkins/.rvm/gems/ruby-2.1.5#tallama-integration/gems/cucumber-1.3.17/lib/cucumber/ast/tree_walker.rb:58:in `block in visit_feature_element'
/var/lib/jenkins/.rvm/gems/ruby-2.1.5#tallama-integration/gems/cucumber-1.3.17/lib/cucumber/ast/tree_walker.rb:170:in `broadcast'
/var/lib/jenkins/.rvm/gems/ruby-2.1.5#tallama-integration/gems/cucumber-1.3.17/lib/cucumber/ast/tree_walker.rb:57:in `visit_feature_element'
/var/lib/jenkins/.rvm/gems/ruby-2.1.5#tallama-integration/gems/cucumber-1.3.17/lib/cucumber/ast/feature.rb:38:in `block in accept'
/var/lib/jenkins/.rvm/gems/ruby-2.1.5#tallama-integration/gems/cucumber-1.3.17/lib/cucumber/ast/feature.rb:37:in `each'
/var/lib/jenkins/.rvm/gems/ruby-2.1.5#tallama-integration/gems/cucumber-1.3.17/lib/cucumber/ast/feature.rb:37:in `accept'
/var/lib/jenkins/.rvm/gems/ruby-2.1.5#tallama-integration/gems/cucumber-1.3.17/lib/cucumber/ast/tree_walker.rb:27:in `block in visit_feature'
/var/lib/jenkins/.rvm/gems/ruby-2.1.5#tallama-integration/gems/cucumber-1.3.17/lib/cucumber/ast/tree_walker.rb:170:in `broadcast'
/var/lib/jenkins/.rvm/gems/ruby-2.1.5#tallama-integration/gems/cucumber-1.3.17/lib/cucumber/ast/tree_walker.rb:26:in `visit_feature'
/var/lib/jenkins/.rvm/gems/ruby-2.1.5#tallama-integration/gems/cucumber-1.3.17/lib/cucumber/ast/features.rb:28:in `block in accept'
/var/lib/jenkins/.rvm/gems/ruby-2.1.5#tallama-integration/gems/cucumber-1.3.17/lib/cucumber/ast/features.rb:17:in `each'
/var/lib/jenkins/.rvm/gems/ruby-2.1.5#tallama-integration/gems/cucumber-1.3.17/lib/cucumber/ast/features.rb:17:in `each'
/var/lib/jenkins/.rvm/gems/ruby-2.1.5#tallama-integration/gems/cucumber-1.3.17/lib/cucumber/ast/features.rb:27:in `accept'
/var/lib/jenkins/.rvm/gems/ruby-2.1.5#tallama-integration/gems/cucumber-1.3.17/lib/cucumber/ast/tree_walker.rb:21:in `block in visit_features'
/var/lib/jenkins/.rvm/gems/ruby-2.1.5#tallama-integration/gems/cucumber-1.3.17/lib/cucumber/ast/tree_walker.rb:170:in `broadcast'
/var/lib/jenkins/.rvm/gems/ruby-2.1.5#tallama-integration/gems/cucumber-1.3.17/lib/cucumber/ast/tree_walker.rb:20:in `visit_features'
/var/lib/jenkins/.rvm/gems/ruby-2.1.5#tallama-integration/gems/cucumber-1.3.17/lib/cucumber/runtime.rb:49:in `run!'
/var/lib/jenkins/.rvm/gems/ruby-2.1.5#tallama-integration/gems/cucumber-1.3.17/lib/cucumber/cli/main.rb:47:in `execute!'
/var/lib/jenkins/.rvm/gems/ruby-2.1.5#tallama-integration/gems/cucumber-1.3.17/bin/cucumber:13:in `'
/var/lib/jenkins/.rvm/gems/ruby-2.1.5#tallama-integration/bin/cucumber:23:in `load'
/var/lib/jenkins/.rvm/gems/ruby-2.1.5#tallama-integration/bin/cucumber:23:in `'
/var/lib/jenkins/.rvm/gems/ruby-2.1.5#tallama-integration/bin/ruby_executable_hooks:15:in `eval'
/var/lib/jenkins/.rvm/gems/ruby-2.1.5#tallama-integration/bin/ruby_executable_hooks:15:in `'
This error is not the same as a closed stream error, which signifies that you're attempting to touch a stream after it's been closed.
No, the only time a stream closed (IOError) is thrown in all of MRI is in rb_thread_fd_close. That code in turn is only called in rb_io_close – aka when closing a file descriptor; it iterates through the other live threads and sees if any of them is waiting for the closed file descriptor. If there’s anybody waiting, it raises the stream closed error in the waiting thread. That neatly explains why the stack trace is pointing to cucumber: that’s the thread that’s waiting to write out to STDOUT, from the formatter. But we don’t have any info on who closed the file descriptor.
Since I know I'm dealing with threads here, I start to suspect timeout is killing something when it shouldn't be, but I have no way of knowing what timeout is causing the mess; I removed the one in my code but then found 35 in various gems we're using, and the issue is still occurring.
We also suspected, at some point, that one of the phantomjs processes was being killed due to low memory, and we added instrumentation to puts the current process' memory before every scenario… and the IOErrors went away, almost certainly because of timing issues. When I removed the instrumentation the errors returned.
I've also attempted to update to tip-of-tree cucumber and capybara, but neither seemed to make a difference.
Is there some clever way to track this down that I've not yet tried? Have you seen this issue and know the one-line configuration change I need to make it better? Do you have a convenient patch that removes timeout from all Ruby everywhere?
Ideas to try...
Narrow the issue by trying Capybara + WebKit; Poltergeist is not thread safe (AFAIK).
Narrow the issue by seeing if it's a Rack timeout:
# config/initializers/timeout.rb
Rack::Timeout.timeout = 600
Rack::Timeout.wait_timeout = 600 # or 0 means never timeout
Temporarily turn off any tests that call to externals, such as system, sidekiq, eventmachine, delayed job, etc.
For your idea of a patch that removes timeout from all Ruby everywhere:
require 'timeout'
Thread.handle_interrupt(TimeoutError => :never) {
timeout(10){
# TimeoutError doesn't occur here
Thread.handle_interrupt(TimeoutError => :on_blocking) {
# possible to be killed by TimeoutError
# while blocking operation
}
# TimeoutError doesn't occur here
}
}
See Guarding from Timeout Error
Track the open file objects at any breakpoints you want:
# List all open File objects.
ObjectSpace.each_object(File) do |f|
puts "%s: %d" % [f.path, f.fileno] unless f.closed?
end
# List the "dangling" File object which we didn't store in a variable.
ObjectSpace.each_object(File) do |f|
unless f.closed?
printf "%s: %d\n", f.path, f.fileno unless f === filehandle
end
end
See Where does Ruby keep track of its open file descriptors
try this out:
In your code after opening the file for reading you must close it.
See this similar issue
I have a setup where a cron job periodically downloads an mp3 file from an external service (Twilio) and then uses Paperclip to upload the file to Amazon S3. The process is handled in the background by Resque.
Here is the code that handles the download from Twilio and subsequent attachment to Paperclip:
# Perform transfer from Twilio to S3
def self.perform(group_recording_id = nil)
gr = GroupRecording.find(group_recording_id)
# ...
recording = TwilioClient.account.recordings.get(gr.external_id)
if recording.present?
# ....
gr.audio_file = download_remote_file(gr.twilio_mp3_url)
gr.save
end
end
def download_remote_file(url)
io = open(URI.parse(url))
# overrides Paperclip::Upfile#original_filename
def io.original_filename
base_uri.path.split('/').last
end
io.original_filename.blank? ? nil : io
end
This fails with EOFErrors :
EOFError
end of file reached
/usr/local/lib/ruby/1.9.1/openssl/buffering.rb:145:in `sysread_nonblock'
/usr/local/lib/ruby/1.9.1/openssl/buffering.rb:145:in `read_nonblock'
/usr/local/lib/ruby/1.9.1/net/protocol.rb:135:in `rbuf_fill'
/usr/local/lib/ruby/1.9.1/net/protocol.rb:116:in `readuntil'
/usr/local/lib/ruby/1.9.1/net/protocol.rb:126:in `readline'
/usr/local/lib/ruby/1.9.1/net/http.rb:2219:in `read_status_line'
/usr/local/lib/ruby/1.9.1/net/http.rb:2208:in `read_new'
/usr/local/lib/ruby/1.9.1/net/http.rb:1191:in `transport_request'
/usr/local/lib/ruby/1.9.1/net/http.rb:1177:in `request'
/app/vendor/bundle/ruby/1.9.1/gems/rest-client-1.6.7/lib/restclient/net_http_ext.rb:51:in `request'
/usr/local/lib/ruby/1.9.1/open-uri.rb:312:in `block in open_http'
/usr/local/lib/ruby/1.9.1/net/http.rb:627:in `start'
/usr/local/lib/ruby/1.9.1/open-uri.rb:306:in `open_http'
/usr/local/lib/ruby/1.9.1/open-uri.rb:769:in `buffer_open'
/usr/local/lib/ruby/1.9.1/open-uri.rb:203:in `block in open_loop'
/usr/local/lib/ruby/1.9.1/open-uri.rb:201:in `catch'
/usr/local/lib/ruby/1.9.1/open-uri.rb:201:in `open_loop'
/usr/local/lib/ruby/1.9.1/open-uri.rb:146:in `open_uri'
/usr/local/lib/ruby/1.9.1/open-uri.rb:671:in `open'
/usr/local/lib/ruby/1.9.1/open-uri.rb:33:in `open'
/app/app/models/group_recording.rb:112:in `download_remote_file'
/app/app/models/group_recording.rb:85:in `perform'
The above is the most common error, but I also encountered this:
Errno::ECONNRESET
Connection reset by peer
/app/vendor/ruby-1.9.2/lib/ruby/1.9.1/openssl/buffering.rb:145:in `sysread_nonblock'
/app/vendor/ruby-1.9.2/lib/ruby/1.9.1/openssl/buffering.rb:145:in `read_nonblock'
/app/vendor/ruby-1.9.2/lib/ruby/1.9.1/net/protocol.rb:135:in `rbuf_fill'
/app/vendor/ruby-1.9.2/lib/ruby/1.9.1/net/protocol.rb:86:in `read'
/app/vendor/ruby-1.9.2/lib/ruby/1.9.1/net/http.rb:2424:in `read_body_0'
/app/vendor/ruby-1.9.2/lib/ruby/1.9.1/net/http.rb:2379:in `read_body'
/app/vendor/ruby-1.9.2/lib/ruby/1.9.1/open-uri.rb:321:in `block (2 levels) in open_http'
/app/vendor/ruby-1.9.2/lib/ruby/1.9.1/net/http.rb:1194:in `block in transport_request'
/app/vendor/ruby-1.9.2/lib/ruby/1.9.1/net/http.rb:2342:in `reading_body'
/app/vendor/ruby-1.9.2/lib/ruby/1.9.1/net/http.rb:1193:in `transport_request'
/app/vendor/ruby-1.9.2/lib/ruby/1.9.1/net/http.rb:1177:in `request'
/app/vendor/bundle/ruby/1.9.1/gems/rest-client-1.6.7/lib/restclient/net_http_ext.rb:51:in `request'
/app/vendor/ruby-1.9.2/lib/ruby/1.9.1/open-uri.rb:312:in `block in open_http'
/app/vendor/ruby-1.9.2/lib/ruby/1.9.1/net/http.rb:627:in `start'
/app/vendor/ruby-1.9.2/lib/ruby/1.9.1/open-uri.rb:306:in `open_http'
/app/vendor/ruby-1.9.2/lib/ruby/1.9.1/open-uri.rb:769:in `buffer_open'
/app/vendor/ruby-1.9.2/lib/ruby/1.9.1/open-uri.rb:203:in `block in open_loop'
/app/vendor/ruby-1.9.2/lib/ruby/1.9.1/open-uri.rb:201:in `catch'
/app/vendor/ruby-1.9.2/lib/ruby/1.9.1/open-uri.rb:201:in `open_loop'
/app/vendor/ruby-1.9.2/lib/ruby/1.9.1/open-uri.rb:146:in `open_uri'
/app/vendor/ruby-1.9.2/lib/ruby/1.9.1/open-uri.rb:671:in `open'
/app/vendor/ruby-1.9.2/lib/ruby/1.9.1/open-uri.rb:33:in `open'
/app/app/models/group_recording.rb:113:in `download_remote_file'
/app/app/models/group_recording.rb:86:in `perform'
The problem is intermittant and just started occurring in heroku's production environment recently without any change in the relevant code. The app is currently on ruby 1.9.3-p429 on heroku. The problem occurs locally as well, but somewhat less frequently. I tried the same and lower ruby versions (as low as 1.9.3-p194).
Has anybody come across a similar issue? Searching for the error online has turned up similar errors, but in vastly different contexts.
These are transient networking errors that you should expect in your code, and retry the operation (usually after a short sleep). The internet is not reliable!
You should log retries, and if you notice a spike or unusual pattern you may want to take it up with your service providers (heroku, twilio, etc) since there may be something on their end they can provide insight into.
There's nothing directly you can do to fix the problem from your code though (if it indeed did not change).
When I open up a page that's using my CSS it will work once, but won't work again until you open up the CSS and re-save it. Every other time I try to directly access my CSS, it works fine. But the other times, it doesn't work and I receive this server output:
[2010-08-01 12:49:37] ERROR NoMethodError: private method `gsub!' called for #<Class:0x7f6d0639ad80>
/usr/lib/ruby/1.8/webrick/htmlutils.rb:16:in `escape'
/usr/lib/ruby/1.8/webrick/httpresponse.rb:232:in `set_error'
/var/www/rails-blog/vendor/rails/railties/lib/webrick_server.rb:94:in `handle_file'
/var/www/rails-blog/vendor/rails/railties/lib/webrick_server.rb:73:in `service'
/usr/lib/ruby/1.8/webrick/httpserver.rb:104:in `service'
/usr/lib/ruby/1.8/webrick/httpserver.rb:65:in `run'
/usr/lib/ruby/1.8/webrick/server.rb:173:in `start_thread'
/usr/lib/ruby/1.8/webrick/server.rb:162:in `start'
/usr/lib/ruby/1.8/webrick/server.rb:162:in `start_thread'
/usr/lib/ruby/1.8/webrick/server.rb:95:in `start'
/usr/lib/ruby/1.8/webrick/server.rb:92:in `each'
/usr/lib/ruby/1.8/webrick/server.rb:92:in `start'
/usr/lib/ruby/1.8/webrick/server.rb:23:in `start'
/usr/lib/ruby/1.8/webrick/server.rb:82:in `start'
/var/www/rails-blog/vendor/rails/railties/lib/webrick_server.rb:60:in `dispatch'
/var/www/rails-blog/vendor/rails/railties/lib/commands/servers/webrick.rb:66
/usr/lib/ruby/1.8/rubygems/custom_require.rb:31:in `gem_original_require'
/usr/lib/ruby/1.8/rubygems/custom_require.rb:31:in `require'
/var/www/rails-blog/vendor/rails/activesupport/lib/active_support/dependencies.rb:153:in `require'
/var/www/rails-blog/vendor/rails/activesupport/lib/active_support/dependencies.rb:521:in `new_constants_in'
/var/www/rails-blog/vendor/rails/activesupport/lib/active_support/dependencies.rb:153:in `require'
/var/www/rails-blog/vendor/rails/railties/lib/commands/server.rb:49
/usr/lib/ruby/1.8/rubygems/custom_require.rb:31:in `gem_original_require'
/usr/lib/ruby/1.8/rubygems/custom_require.rb:31:in `require'
script/server:3
127.0.0.1 - - [01/Aug/2010:12:49:37 BST] "GET /stylesheets/scaffold.css HTTP/1.1" 500 343
- -> /stylesheets/scaffold.css?1280662371
The code I'm using to include the stylesheet is <%= stylesheet_link_tag 'scaffold' %>. I've restarted the Ruby server but with no effect. What could be causing this problem?
This is from reading one of the official guides.
This does not happen when running Mongrel.
This is a bug in WEBrick, see http://www.ruby-forum.com/topic/206225.
On 10.06.2010 03:19, Michael Pitman (mcp) posted:
To continue using Webrick, instead of
switching to Mongrel, you can also
just edit line 15 of
lib/ruby/1.8/webrick/htmlutils.rb to
read
str = string ? string.to_s.dup : ""
The problem is that NotModified
exception is getting passed to
HTMLUtils::escape as a class, rather
than a string (originally raised in
HTTPServlet::DefaultFileHandler).
Since the only things that can really
be HTML escaped are strings, it should
be safe to always convert the input
to string.
I suspect that the potential
performance penalty may prevent a
solution like that from making it to
the standard ruby library, but it's a
simple workaround.
Alternatively, in the handle_file
method of webrick's DispatchServlet
(lib/webrick_server.rb in the rails
gem), before it calls res.set_error
with the exception, you could force
the err.message to be a string, or
even clear the message, since I think
it's discarded anyway for
NotModified.
Michael