Mandrill-api Excon :: Błędy :: SocketError

Question

Używam Mandrill-api w Ruby do programowego wysyłania e-maili transakcyjnych.

mam (bardziej lub mniej) dodaje się wiersz w moim app szyn,

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

Problem jest podczas pracy w produkcji, zwraca następujący błąd raz na jakiś czas.

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

Nie mam pojęcia, jak rozwiązać ten problem. Jeśli ktoś mógłby rzucić mi trochę światła na podejście do debugowania tego, bardzo to doceniam.

Gems Info:

• mandryl-api (1.0.33)
• EXCON (0.16.10)

env Produkcja:

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 

Running on:

Serwer Apache: Apache /2.2.22 (Ubuntu)

Pasażer: 3.0.14

Answer 1

Najprawdopodobniej jest to przekroczenie limitu czasu gniazda. Excon próbuje używać trwałych połączeń, kiedy tylko może, ale czasami wraca, by nas ugryźć. Wygląda na to, że mandrill-api próbuje ponownie użyć tego samego połączenia/gniazda w swojej metodzie wywołania: https://bitbucket.org/mailchimp/mandrill-api-ruby/src/03e3e28e77dcba31eab7d2f9e2216b5a01d2110d/lib/mandrill.rb?at=master#cl-35

To powinno normalnie być w porządku, ale może prowadzić do zachowania, które widzisz powyżej, jeśli dana sesja żyje przez dłuższy czas (tj. prawdopodobnie więcej niż 30 sekund, według przypuszczeń). Wywołanie funkcji #reset w połączeniu excon zapewniłoby, że tego nie napotkasz, więc jest to prawdopodobnie najbezpieczniejszy sposób (chociaż zapobiega to używaniu trwałych połączeń, więc wystąpiłaby niewielka poprawa wydajności, jeśli wykonujesz wiele żądań).

Mam nadzieję, że pomoże, być może powinniśmy omówić z mandrill-api o aktualizacji tego. Może zależeć tylko od tego, jak sporadycznie (lub nie) jest problem, biorąc pod uwagę uderzenie wydajnościowe. Mam nadzieję, że pomaga, ale na pewno chętnie omawiam/pomagam, ale mogę.

Answer 2

To może mieć coś wspólnego z utrzymaniem gniazdo otwarte poza jej wygaśnięciem, biorąc pod uwagę, że jest to błąd EOF i jest przerywany.

Czy są jakieś ustawienia otwierania nowego gniazda przy każdym żądaniu, zamiast ponownego użycia tego samego?