J’utilise Workling + Starling pour exécuter des traitements en tâche
de fond dans une application Rails. Tout fonctionne très bien mais je
me demande quelle est la meilleure méthode pour afficher l’état de
traitement des tâches de starling dans mon site Rails.
Pensez vous que l’idée de logger les jobs dans une table en mettant à
jour cette table directement depuis le Worker est bonne ?
Ceci me permettrait par exemple d’afficher l’état de tous mes jobs
envoyés à Starling dans une zone de mon site qui serait consultable
par tous les utilisateurs qui attendent potentiellement le résultat
d’un job.
J’utilise Workling + Starling pour exécuter des traitements en tâche
de fond dans une application Rails. Tout fonctionne très bien mais je
me demande quelle est la meilleure méthode pour afficher l’état de
traitement des tâches de starling dans mon site Rails.
Pensez vous que l’idée de logger les jobs dans une table en mettant à
jour cette table directement depuis le Worker est bonne ?
Ca dépend de ce que tu veux faire, si je me souviens bien Workling
avec starling a un système de retour d’info (qui passe tout simplement
par Starling, les jobs mettent des infos dans la queue et le serveur
peut aller les chercher), tu obtiens un job_id quand tu lances ta
tache asynchrone et ensuite tu peux poller pour savoir ou en est ton
job si tu as correctement implémenté cela dans ton job (pour plus de
précision lire le README). Dans le pratique c’est pratique afficher
une barre de progression en ajax par exemple mais ce n’est pas adapté
pour une page globale avec tous les jobs vu par plusieurs
utilisateurs, car dans ce cas tu vas effectivement devoir stocker les
job_id et leur état (fini, commencé, en cours …) (starling est une
queue il n’y a pas de stockage persistent de l’historique, ni
d’accèspartagé à l’info de status).
(starling est une queue il n’y a pas de stockage persistent
de l’historique,
En fait la classe PersistentQueue dans Starling, c’est du
pipeau ?
Je me suis mal exprimé, il y a un stockage persistant de la queue qui
fait qu’en cas de serveur reboot on ne perd rien mais ca fonctionne
comme une stack = ca ne supporte en gros que 2 opération pull/push GET/
SET. On est pas dans du protocol AMQP qui propose des mode de
comportement distinct. En particulier: on ne peut pas lire un élément
d’une queue autrement qu’en le dépilant
Une fois un element dépilé, pouf il est parti dans le client qui l’a
dépilé et le serveur la complètement oublié. Donc pour monitorer un
status c’est pas top car quand un worker starling met comme le status
Y pour le job_id X (c’est à dire empile à la queue X la valeur Y) et
bien quand un client vient lire cette valeur, il la dépile (GET =
depile dans starling au contraire de memcache), si un 2 ème client
arrive elle n’y est plus.
Ce qui fait qu’un seul client ne réussira à fetcher la valeur Y,
ensuite elle est dépilée. Donc pour faire un dashboard de status de
job, ca n’est pas adapté, pour le support du feedback d’un user qui
poll en ajax pour savoir quand sa tache se termine et déclencher un
comportement quand c’est fini c’est suffisant.
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.