Статус рендеринга 200 перед выполнением кода в контроллере рельсов

Я интегрирую коммуникационный API, и всякий раз, когда текст/голос достигает моего сервера (контроллера рельсов), я должен отправить обратно OK (200) в API. Я хочу отправить этот ответ перед выполнением моего блока кода, потому что, если мой код сломается (и не сможет отправить OK), API связи будет отправлять сообщения до 3 дней. Теперь это только усложняет проблему уже на моем сервере, потому что он будет продолжать ломаться, поскольку одно и то же сообщение продолжает поступать.

Я провел небольшое исследование и нашел два решения.

Решение 1. Первое решение приведено ниже (моя текущая реализация), и оно, похоже, не работает (если только я не прочитал файлы журнала должным образом или у меня галлюцинации).

def receive_text_message
   head :ok, :content_type => 'text/html'   
   # A bunch of code down here
end

Я думал, что это должно сработать (согласно документации по рельсам), но я не уверен, что это так.

Решение 2: вторая реализация, которую я обдумываю, состоит в том, чтобы быстро создать новый процесс/поток для выполнения блока кода и убить процесс, получивший сообщение... таким образом, API получит свое OK очень быстро, и ему не нужно ждать успешного выполнения моего блока кода. Я мог бы использовать нерестовый (или нерестовый) драгоценный камень, чтобы сделать это. Я бы пошел с созданием процесса, так как я использую пассажирский (общественный) сервер. Но новые процессы будут потреблять больше оперативной памяти, плюс я думаю, что сложнее отлаживать дочерние процессы/потоки (я могу ошибаться в этом)

Спасибо за помощь!

Дополнительный вопрос: пытается ли rails перезапустить процесс после того, как он только что потерпел неудачу?


ruby ruby-on-rails model-view-controller ruby-on-rails-4
person justcode    schedule 14.04.2014    source источник
comment
Это может вас заинтересовать edgar. tumblr.com/post/9880562940/   -  person MrYoshiji    schedule 14.04.2014
comment
Я согласен с решением № 2. Вы можете использовать что-то вроде Resque или Sidekiq и ставить задания в очередь, чтобы выполнять их в свое время.   -  person Kurt Funai    schedule 14.04.2014
comment
MrYoshiji я посмотрю. @Kurt Funai Я бы предпочел не использовать Resque и компанию. Но я думаю, что Sidekiq — чистая альтернатива жемчужине Spawling. Но просто чтобы быть уверенным, как только я вызову метод sidekiq Perform_async в вышеприведенном контроллере, завершится ли этот контроллер и вернется ли он?   -  person justcode    schedule 14.04.2014
comment
У меня лично есть опыт работы только с Resque, но да, после постановки задачи в очередь контроллер продолжит выполнение. Он не ждет, пока сервер утилит обработает задание, прежде чем продолжить. Все, что у вас есть после выполнения execute_async, будет выполнено (например, ваше возвращение).   -  person Kurt Funai    schedule 15.04.2014

Ответы (1)


arrow_upward
2
arrow_downward

Вы можете выбрать возврат 200 в свой контроллер и запустить задание sidekiq. Таким образом, 200 будут немедленно возвращены, и ваш контроллер будет готов к обработке следующего задания. Так что не тратьте время и ресурсы на свой контроллер. Позвольте работнику сделать настоящую тяжелую работу.

В вашем контроллере

def receive_text_message
   head :ok, :content_type => 'text/html'   
   HardWorker.perform_async(params)
end

В вашем помощнике:

class HardWorker
  include Sidekiq::Worker

  def perform(params)
    # 'Doing hard work'
  end
end

Мне нравится sidekiq в основном потому, что он лучше обрабатывает ресурсы по сравнению со спасением.

person Boti    schedule 15.04.2014
comment
@Boti...lol Думаю, мне нравится этот вариант. Это гибрид двух решений. Я попробую позже на этой неделе. из любопытства... значит, без sidekiq вы говорите, что мой контроллер не сможет обрабатывать новые запросы, пока блок кода не выполнится полностью? - person justcode; 15.04.2014