Mandrill：：Error：：SocketError

Question

我正在使用Ruby中的Mandrill-api以编程方式发送事务性电子邮件。

我的rails应用程序中有(或多或少)下面一行，

mandrill ||= Mandrill::API.new const(:API)[:MANDRILL_APIKEY]
... (constructing the message, content, etc)
mandrill.messages.send_template templ, template_content, message, true

问题是在生产中运行时，它会不时地返回以下错误()。

Excon::Errors::SocketError (EOFError (EOFError)):
app/mailers/mailer.rb:24:in `send'
....

我不知道如何调试这个问题。如果有人能让我了解一下调试这个程序的方法，我非常感激。

Gems信息：

• 芒钻-空气污染指数(1.0.33)
• excon (0.16.10)

生产env：

 sudo bundle exec rake RAILS_ENV=production about


About your application's environment
Ruby version              1.9.3 (x86_64-linux)
RubyGems version          1.8.11
Rack version              1.4
Rails version             3.2.13
Active Record version     3.2.13
Action Pack version       3.2.13
Active Resource version   3.2.13
Action Mailer version     3.2.13
Active Support version    3.2.13
Middleware                Rack::Cache, Rack::Lock, #<ActiveSupport::Cache::Strategy::LocalCache::Middleware:0x00000001e72330>, Rack::Runtime, Rack::MethodOverride, ActionDispatch::RequestId, Rails::Rack::Logger, ActionDispatch::ShowExceptions, ActionDispatch::DebugExceptions, ActionDispatch::RemoteIp, ActionDispatch::Callbacks, ActiveRecord::ConnectionAdapters::ConnectionManagement, ActiveRecord::QueryCache, ActionDispatch::Cookies, ActionDispatch::Session::CookieStore, ActionDispatch::Flash, ActionDispatch::ParamsParser, ActionDispatch::Head, Rack::ConditionalGet, Rack::ETag, ActionDispatch::BestStandardsSupport
Environment               production
Database adapter          mysql2

继续运行：

Apache服务器: Apache/2.2.22 (Ubuntu)

乘客: 3.0.14

Answer 1

很可能是套接字超时。Excon试图在可能的情况下使用持久的连接，但有时它会很不幸地回来咬我们。似乎mandrill试图在它的调用方法：https://bitbucket.org/mailchimp/mandrill-api-ruby/src/03e3e28e77dcba31eab7d2f9e2216b5a01d2110d/lib/mandrill.rb?at=master#cl-35中重用相同的连接/套接字。

这通常应该是好的，但如果给定的会话持续更长的时间(根据猜测可能超过30秒)，则可能会导致您在上面看到的行为。在excon连接上调用#reset将确保您不会遇到这种情况，所以这可能是最安全的方法(尽管这样可以防止持久连接被使用，所以如果您执行了大量请求，性能就会受到很小的影响)。

我希望这会有所帮助，也许我们应该和mandrill讨论一下更新这个问题。考虑到所涉及的性能问题，这可能仅仅取决于问题的间歇性(或不间歇性)。希望这会有所帮助，但我很乐意尽我所能讨论/帮助。

Answer 2

考虑到它是EOF错误并且是间歇性的，它可能与保持套接字在过期后打开有关。

是否存在打开每个请求的新套接字的设置，而不是重用相同的套接字？