#delayed_job

Quelles alternatives ?

Rails ne propose aucun mécanisme pour exécuter du code à un instant t. Il est vrai que le code de l'application est chargé en mémoire, mais ce code demeure dormant jusqu'à ce que l'instance de votre application soit invoquée ou forkée par l'arrivée d'une requête HTTP.

Le plus simple moyen d'exécuter du code de façon périodique est de créer une tâche rake et programmer l'exécution de celle-là via le crontab du système, mais cette approche a plusieurs inconvénients :

Prévilèges système : devoir avoir accès à l'édition de crontab, qui passe par une session ssh, voir des droits root selon la configuration de votre intégration Rails avec le serveur Web.

Lenteur : l'exécution d'une rake task requiert généralement le rechargement quasi complet du code de votre application et de ses dépendances (gems). Si votre application contient beaucoup de code, ce temps de chargement peut atteindre des dizaines de secondes. Compromettant si votre application doit s'exécuter à des intervalles rapprochés.

Régidité : le timing d'exécution des tâches est écrit en dur dans le fichier crontab et ne peut donc pas être changé dynamiquement sur votre application. 

Dispersion de l'information : le timing d'exécution de votre code est une information qui sort de votre application. Elle n'est pas versionnée et peut se perdre.

Pourquoi DelayedJob ?

Delayed Job fonctionne en faisant tourner des workers qui vérifient continuellement dans la table delayed_jobs l'existence de tâches en attente et dont la date d'exécution est arrivée.

C'est cette mécanique bien huilée que nous exploiterons.

Réalisation

Le modèle central de delayed_job est Delayed::Job. Créons à notre tour Delayed::Cron dont hériteront tous les jobs qui devront être exécutés périodiquement. De cette manière : 

CODE 1

CODE 2

Rien de vraiment spécial, si ce n'est que FunnyJob utilise comme méthode macro la méthode de classe every qu'elle hérite de Delayed::Cron.

Maintenant, enregistrons ces paramètres dans une classe dédiée et élaborons la logique qui permet de calculer le prochain délai d'exécution de la tâche : 

CODE 3

params_list.rb

next_term.rb

La classe ParamsList enregistre le paramétrage du cron et le complète avec des paramètres par défaut (ligne 23). NextTerm calcule quant à elle le prochain délai d'exécution en devinant la date la plus proche et en s'assurant via la méthode futur! (ligne 17) que cette date n'est pas passée.

Planifions tout cela !

L'idée est de s'assurer que chaque cron planifie la prochaine exécution, même en cas d'échec (voir le ensure lignes 7 et 8)

cron.rb

Delayed Jobs exécute la méthode perform des jobs passés à Delayed::Job.enqueue. Le code qui utilise les crons doit concentrer sa logique dans la méthode perform_cron qui sera à son tour appelée par perform.

À la planification, nous nous assurons qu'aucune tâche planifiée n'a été dédoublée. Si c'est le cas, clean_up se charge de supprimer les improbables doublons.

Renforcer la sécurité en chargeant les crons au démarrage

S'il arrive un pépin au moment de l'exécution du bloc ensure ou si l'échec de l'exécution du job fait crasher tout le worker, la chaine est brisée et une intervention manuelle sera nécessaire pour la rétablir. C'est pourquoi nous exécuterons la méthode schedule de tous les jobs au chargement de l'environnement de l'application, qui survient également au démarrage des workers et autres consoles ou rake tasks.

cron.rb

Nous avons ajouté deux méthodes de classe à Delayed::Cron. Nous pouvons passer à load une liste de classes à surveiller au démarrage de l'environnement.

Ou appeler load_all qui charge toutes les classes présentes dans le dossier app/crons. Ce dossier peut être personnalisé dans l'unique paramètre que prend cette méthode. Load_all ajoute ce dossier aux chemins d'autoload de l'application (ligne 46).

Notons à la ligne 40 l'utilisation de logger.silence qui empêche l'application de journaliser tout cela. Le démarrage de l'application en mode console (rails c) ne sera donc pas pollué.

Ces appels se font idéalement dans un initializer (exemple : config/initializers/delayed_crons.rb

delayed_crons.rb

Conserver les crons qui échouent sans les rééxécuter

Delayed Jobs permet de conserver les jobs qui fail mais ne donne pas la possibilité de choisir lesquels. Ils sont soit tous retenus soit tous supprimés suivant le paramètre global Delayed::Worker.destroy_failed_jobs = true|false.

Nous devons donc ruser pour conserver, pour des raisons de débogage, les crons qui échouent, mais nous ne pouvons pas leur permettre de s'exécuter d'autres fois. Leurs échéances auront passé et ils risquent de perturber ou dédoubler les prochaines exécutions.

config.rb

config.rb

Nous permettons (en théorie) au cron de s'exécuter deux fois, sauf que la deuxième exécution n'aura pas lieu de sitôt ! Si quelqu'un trouve une idée plus propre qu'il nous en fait part.

Et pourquoi pas la syntaxe `cron` ?

Nous ne pouvons évidemment parler de crons sans leur célèbre syntaxe étoilée (!) : mm hh jj MMM JJJ (minutes, heures, jour du mois, mois et jour de semaine). Essayons de rendre possible une telle utilisation :

config.rb

Dans cette implémentation, la classe CronFormat parse la fameuse chaine étoilée et devine la fréquence adéquate et les paramètres nécessaires. :

cron_format.rb

params_list.rb

Worker dédié

Si vous en avez la possibilité, reservez au moins un worker DelayedJob à la queue `delayed_crons`.

Le worker dédié pourra être lancé de cette manière, à partir de vos tâches Capistrano, vos pillules bluepill ou autre !

delayed_job -i 1 --queue=delayed_crons start

Conclusion

Dans cet article, nous avons étudié l'approche globale de l'exploitation de DelayedJobs pour effectuer des tâches répétitives. Nous planifions la prochaine exécution d'une tâche à chaque exécution et — en backup — à chaque lancement de l'environnement.