Forum: Rails France Workling+Starling : suivi des jobs

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
A1bccd782c0513cf7df8daf08b371c81?d=identicon&s=25 Osaris (Guest)
on 2009-01-15 16:22
(Received via mailing list)
Bonjour,

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.

Merci pour vos conseils !
4a7982065027f6678cf86fd469d34f08?d=identicon&s=25 Renaud (Nel) Morvan (Guest)
on 2009-01-16 01:12
(Received via mailing list)
On Jan 15, 4:21 pm, Osaris <Raphael.Emourg...@gmail.com> wrote:
> Bonjour,
>
> 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).
A99870c1391c39da2089649745965bda?d=identicon&s=25 Jean-François Trân (Guest)
on 2009-01-16 15:33
(Received via mailing list)
Le 16 janvier 2009 01:11, Renaud a écrit :
> (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 ?

   -- Jean-François.

--
http://twitter.com/underflow_
4a7982065027f6678cf86fd469d34f08?d=identicon&s=25 Renaud (Nel) Morvan (Guest)
on 2009-01-18 02:11
(Received via mailing list)
On 16 jan, 15:32, Jean-François Trân <jft...@rubyfrance.org> wrote:
> Le 16 janvier 2009 01:11, Renaud a écrit :
>
> > (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 topic is locked and can not be replied to.