通过拼音OpenURI下载文件时的间歇EOFError

Question

我有一个设置，一个cron作业定期从外部服务(Twilio)下载一个mp3文件，然后使用回形针将文件上传到亚马逊S3。该过程由Resque在后台处理。

下面是处理从Twilio下载的代码，以及随后附加到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

对于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'

上面是最常见的错误，但我也遇到了这样的错误：

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'

这个问题是间歇性的，最近才开始在heroku的生产环境中发生，相关代码没有任何变化。该应用程序目前在heroku上的ruby 1.9.3-p429上。这个问题在本地也会发生，但频率稍低一些。我尝试了相同的更低版本的ruby (低至1.9.3-p194)。

有没有人遇到过类似的问题？在网上搜索错误也出现了类似的错误，但在非常不同的上下文中。

Answer 1

这些都是短暂的网络错误，您应该在代码中预料到这些错误，然后重试该操作(通常在短暂睡眠之后)。互联网是不可靠的！

你应该记录重试，如果你注意到一个峰值或不寻常的模式，你可能想要与你的服务提供商(heroku，twilio等)联系，因为他们可能会提供一些洞察。

但是，您无法直接从代码中修复该问题(如果它确实没有更改)。