ActiveResource 超时不起作用[重复]答案

【问题标题】：ActiveResource timeout not functioning [duplicate]ActiveResource 超时不起作用[重复]
【发布时间】：2009-07-16 06:02:47
【问题描述】：

我正在尝试使用 ActiveResource on Rails 2.3.2 联系 REST API。

我正在尝试使用超时功能，以便如果我正在联系的资源出现故障，我可以快速失败 - 我正在执行以下操作：

class WorkspaceResource < ActiveResource::Base
  self.timeout = 5
  self.site = "http://mysite.com/restAPI"
end

但是，当我知道该服务不可用时尝试联系该服务时，该课程只会在默认的 60 秒后超时。我可以从错误堆栈中看到，超时错误确实来自我的 gem 文件夹中的 ActiveResource 类，该类具有允许超时设置的适当功能，但我设置的超时似乎永远不会起作用。

有什么想法吗？

所以显然问题不在于超时不起作用。我可以在本地运行服务器，使其在超时限制内不返回响应，然后查看超时是否有效。

问题实际上是，如果服务器不接受连接，超时不会像我预期的那样起作用 - 它根本不起作用。似乎超时仅在服务器接受连接但响应时间过长时才有效。

对我来说，这似乎是一个问题——当我联系的服务器关闭时，超时不应该也起作用吗？如果没有，应该有另一种机制来阻止一堆请求挂起......谁知道快速的方法来做到这一点？

【问题讨论】：

标签： ruby-on-rails ruby timeout

【解决方案1】：

问题

如果您在 Ruby 1.8.x 上运行，那么问题在于它缺少真正的系统线程。

如您所见first here和then here，Ruby 中的超时存在系统性问题。一个有趣的讨论，但特别是对您而言，一些 cmets 建议超时被有效忽略并默认为 60 秒 - 正是您所看到的。

解决方案 ...

我在尝试发送电子邮件时遇到了与我们自己的产品类似的问题 - 如果电子邮件服务器已关闭线程块。对我来说，解决方案是在单独的线程上关闭请求，因此我的主请求处理线程不会阻塞。

有用于 Ruby 的非阻塞库，但也许您可以先看看这个System Timeout Gem。

对任何在 nginx 等代理后面使用 Rails 的人开放的选项是将上游超时设置为较低的数字 - 这样，如果服务器花费的时间过长，您就会收到通知。如果我真的被困在解决方案中，我只会这样做。

最后但同样重要的是，在 Ruby 1.9.1 之上运行 Rails 2.3.2 可能会解决此问题。

【讨论】：

感谢您的回复 - 我使用的是 2.3.2，我认为线程不是问题 - 请参阅下面的评论

【解决方案2】：

或者，您可以尝试捕获这些连接错误并重试一次（在一定时间后），以确保连接确实断开。

      retried = false
      begin
        @businesses = Business.find(:all, :params => { :shop_domain => @shop.domain })
        retried = false
      rescue ActiveResource::TimeoutError => ex          

      #raise ex

      rescue ActiveResource::ConnectionError, ActiveResource::ServerError, ActiveResource::ClientError => ex
        unless retried           
          sleep(((ex.respond_to?(:response) && ex.response['Retry-After']) || 5).to_i)
          retried = true             
          retry
        else              
          # raise ex
        end
      end

灵感来自 Shopify 用于对大量记录进行分页的解决方案。 https://ecommerce.shopify.com/c/shopify-apis-and-technology/t/paginate-api-results-113066

【讨论】：