Quelles sont les raisons possibles pour Sidekiq d'empêcher le traitement de tâches en attente? La file d'attente est pleine. Le fichier journal sidekiq.log
indique aucune activité. Ainsi, la file d'attente est pleine mais le journal est vide et Sidekiq ne semble pas traiter les éléments. Il ne semble y avoir aucun travail de traitement des travailleurs. Redémarrez Redis ou rincez-le avec FLUSHALL ou FLUSHDB sans effet. Sidekiq a été commencé avec
bundle exec sidekiq -L log/sidekiq.log
et produit le fichier journal suivant:
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
Comment pouvez-vous savoir ce qui ne va pas? Y a-t-il des fichiers de log cachés?
La raison était dans notre cas: Sidekiq peut rechercher la mauvaise file d'attente. Par défaut, Sidekiq utilise une file d'attente nommée "default". Nous avons utilisé deux noms de file d'attente différents et les avons définis dans config/sidekiq.yml
# configuration file for Sidekiq
:queues:
- queue_name_1
- queue_name_2
Le problème est que ce fichier de configuration n'est pas automatiquement chargé par défaut dans votre environnement de développement (à la différence de database.yml
ou thinking_sphinx.yml
par exemple) par une simple commande bundle exec sidekiq
. Nous avons donc écrit nos tâches dans deux files d’attente, et Sidekiq attendait les tâches d’une troisième file (celle par défaut). Vous devez passer le chemin du fichier de configuration en tant que paramètre via l'option -C
ou --config
:
bundle exec sidekiq -C ./config/sidekiq.yml
ou vous pouvez passer directement les noms des files d'attente (aucun espace n'est autorisé après la virgule):
bundle exec sidekiq -q queue_name_1,queue_name_2
Pour identifier le problème, il est également utile de passer l'option -v
ou --verbose
en ligne de commande ou d'utiliser :verbose: true
dans le fichier sidekiq.yml
. Tout ce qui est défini dans un fichier de configuration est évidemment inutile si le fichier de configuration n'est pas chargé. Par conséquent, assurez-vous d'utiliser le bon fichier de configuration en premier.
Si vous avez un config/sidekiq.yml
pour vérifier que toutes les files d'attente y sont définies, consultez le fichier exemple: https://github.com/mperham/sidekiq/blob/master/examples/config.yml
Si vous transmettez des noms de file d'attente dans la ligne de commande ou Procfile, quelque chose de similaire à
bin/sidekiq -q queue1 -q queue2
bundle exec sidekiq -q queue1 -q queue2
vérifiez que toutes vos files d'attente y sont définies.
Si vous n'êtes pas sûr du nom de vos files d'attente, vous pouvez le résoudre avec le script suivant:
require "sidekiq/api"
stats = Sidekiq::Stats.new
stats.queues
# {"production_mailers"=>25, "production_default"=>1}
Ensuite, vous pouvez faire des choses avec les files d'attente:
queue = Sidekiq::Queue.new("production_mailers")
queue.count
queue.clear
Je viens d'avoir ce problème. Il s'avère que j'ai commis une erreur de syntaxe dans mon sidekiq.yml
Dans mon cas, sidekiq était en bon développement, mais bloqué dans la mise en scène. C'était une erreur humaine sur la configuration de déploiement du capistrano. J'ai mal défini le chemin pour sidekiq.yml dans le fichier Capfile (partagé au lieu de actuel).
Il a échoué silencieusement:
# Capfile
# WRONG:
set :sidekiq_config, -> { File.join(shared_path, 'config', 'sidekiq.yml') }
^^^^^^^^^^^
# RIGHT:
set :sidekiq_config, -> { File.join(current_path, 'config', 'sidekiq.yml') }
Mon problème était que j'avais un configure_server mais pas configure_client dans mon initialiseur, vous devez avoir les deux:
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