Sidekiq не обрабатывает очередь

Какие возможные причины могут Sidekiq предотвратить обработку заданий в очереди? Очередь заполнена. Файл журнала sidekiq.log не указывает на активность вообще. Таким образом, очередь заполнена, но журнал пуст, и Sidekiq, похоже, не обрабатывает элементы. Кажется, что рабочие не обрабатывают рабочие места. Перезапустите Redis или запустите его с помощью FLUSHALL или FLUSHDB как никакой эффект. Sidekiq запущен с помощью

bundle exec sidekiq -L log/sidekiq.log

и выдает следующий файл журнала:

2013-05-30..Booting Sidekiq 2.12.0 using redis://localhost:6379/0 with options {}
2013-05-30..Running in ruby 1.9.3p374 (2013-01-15 revision 38858) [i686-linux]
2013-05-30..See LICENSE and the LGPL-3.0 for licensing details.
2013-05-30..Starting processing, hit Ctrl-C to stop

Как вы можете узнать, что пошло не так? Есть ли скрытые файлы журналов?

Ответ 1

Причина в нашем случае: Sidekiq может искать неправильную очередь. По умолчанию Sidekiq использует очередь с именем "default". Мы использовали два разных имени очереди и определили их в config/sidekiq.yml

# configuration file for Sidekiq
:queues:
  - queue_name_1
  - queue_name_2

Проблема заключается в том, что этот конфигурационный файл не загружается автоматически по умолчанию в вашей среде разработки (в отличие от database.yml или thinking_sphinx.yml) с помощью простой команды bundle exec sidekiq. Таким образом, мы написали наши задания в двух определенных очередях, и Sidekiq ждал заданий в третьей очереди (по умолчанию). Вы должны передать путь к конфигурационному файлу в качестве параметра через параметр -C или --config:

bundle exec sidekiq -C ./config/sidekiq.yml

или вы можете передать имена очередей напрямую (без пробелов здесь после запятой):

bundle exec sidekiq -q queue_name_1,queue_name_2

Чтобы найти проблему, полезно передать опцию -v или --verbose в командной строке или использовать :verbose: true в файле sidekiq.yml. Все, что определено в файле конфигурации, конечно, бесполезно, если файл конфигурации не загружен. Поэтому сначала убедитесь, что вы используете правильный конфигурационный файл.

Ответ 2

Если у вас есть config/sidekiq.yml проверьте, что там определены все очереди, проверьте этот пример файла: https://github.com/mperham/sidekiq/blob/master/examples/config.yml

Если вы передаете имена очереди в командной строке или в Procfile, что-то похожее на

bin/sidekiq -q queue1 -q queue2
bundle exec sidekiq -q queue1 -q queue2

проверьте, что все ваши очереди определены там.

Если вы не уверены в названиях своих очередей, вы можете выяснить это с помощью следующего скрипта:

require "sidekiq/api"
stats = Sidekiq::Stats.new
stats.queues
# {"production_mailers"=>25, "production_default"=>1}

Затем вы можете делать вещи с очередями:

queue = Sidekiq::Queue.new("production_mailers")
queue.count
queue.clear

Ответ 3

У меня была эта проблема. Оказывается, я сделал синтаксическую ошибку в моей sidekiq.yml

Ответ 4

В моем случае, sidekiq был хорош в разработке, но застрял в постановке. Это была человеческая ошибка в конфигурации развертывания capistrano. Я неправильно указал путь для sidekiq.yml в Capfile (общий вместо текущего).

Это молча провалилось:

# Capfile

# WRONG:
set :sidekiq_config, -> { File.join(shared_path, 'config', 'sidekiq.yml') }
                                    ^^^^^^^^^^^
# RIGHT:
set :sidekiq_config, -> { File.join(current_path, 'config', 'sidekiq.yml') }

Ответ 5

Моя проблема была в том, что у меня был configure_server, но не configure_client в моем инициализаторе, вы должны иметь оба:

Sidekiq.configure_server do |config|
  config.redis = { url: ENV.fetch('SIDEKIQ_REDIS_URL', 'redis://127.0.0.1:6379/1') }
end

Sidekiq.configure_client do |config|
  config.redis = { url: ENV.fetch('SIDEKIQ_REDIS_URL', 'redis://127.0.0.1:6379/1') }
end

Ответ 6

Я какое-то время стучал головой о кирпичную стену, моя проблема заключалась в том, что sidekiq требовал более новой версии redis-сервера. Я запускал "bundle exec sidekiq" и обнаружил ошибку. Как только я обновился до новой версии redis-сервера, все было в порядке.