ActionNotFound при загрузке приложения

Question

У меня есть странная проблема с моим приложением Rails 4.1.4, запущенным на нескольких экземплярах Puma. Приложение имеет API, который попадает в другие системы в архитектуре SOA. У нас есть система с высоким трафиком, и она получает много звонков. Если при запуске приложения, у нас есть клиенты, призывающие один из наших конечных точек (называемых треком), то кажется, что некоторые работники Puma не загружать классы в память правильно, и мы начинаем получать ошибки как:

FATAL -- : 
AbstractController::ActionNotFound (The action 'track' could not be found for ArticlesController): 
    vendor/bundle/ruby/1.9.1/gems/actionpack-4.1.4/lib/abstract_controller/base.rb:131:in `process' 
    vendor/bundle/ruby/1.9.1/gems/actionview-4.1.4/lib/action_view/rendering.rb:30:in `process' 

и ...

FATAL -- : 
AbstractController::ActionNotFound (The action 'find' could not be found for MatchesController): 
    vendor/bundle/ruby/1.9.1/gems/actionpack-4.1.4/lib/abstract_controller/base.rb:131:in `process' 
    vendor/bundle/ruby/1.9.1/gems/actionview-4.1.4/lib/action_view/rendering.rb:30:in `process' 

Обратите внимание, что событие трек только на ArticlesController, но что-то происходит, где он не может делать запросы в отношении любого контроллера, как только мы получим в этой ситуации.

Если я отключу вызовы на трек конечной точки от клиентов, и я откажу свое приложение, все работает нормально. Если я подожду до тех пор, пока система не выйдет и не включит дорожку , то все будет по-прежнему в порядке.

Проблема возникает только в том случае, когда во время загрузки приложения происходит звонок .

Я не знаю, какую информацию предоставить, чтобы помочь диагностировать эту проблему. Я добавлю более подробную информацию к вопросу, если кто-нибудь знает, как подойти к отладке этого.

Answer 1

Я не уверен, в чем заключается основная проблема, но, похоже, она имеет какое-то отношение к отсутствию безопасности потока во время обвязки загрузки приложения. Решение для бандажей, чтобы избежать этой ошибки, состоит в том, чтобы настроить Puma на использование 1 потока на одного работника.

Вот содержание моего конфиг/puma.rb:

Перед

... 
threads 1,2 
workers 6 
preload_app! 

После -

... 
threads 1,1 
workers 12 
preload_app! 

Это работает, но, к сожалению, это своего рода поражения цели использования сервер, поддерживающий потоки.