Bonjour,
J'aimerais savoir si il existe une méthode pour que le job manager soit géré comme un service ?
D'autre part, nous faisons beaucoup d'importations pour démarrer avec creme et le job manager plante de manière régulière sans erreur particulière... Parfois le process reste actif mais le front n'arrive pas à la joindre ... Si suis en quête d'idées !
Merci par avance
Bien à vous
Bonjour,
> J'aimerais savoir si il existe une méthode pour que le job manager soit géré comme un service ?
La commande est pensée pour que chaque administrateur puisse gérer le manager comme bon lui-semble (on essaie d'éviter les choix qui vont être contraignant derrière).
Si vous regardez dans le répertoire "docker/" (qui décrit l'image docker qu'on distribue à des fin de démo), nous utilisons 'supervisord' pour qu'il se charge de lancer le manager. Peut-être que cette méthode vous satisfera.
> D'autre part, nous faisons beaucoup d'importations pour démarrer avec creme et le job manager plante de manière régulière sans erreur particulière... Parfois le process reste actif mais le front n'arrive pas à la joindre ... Si suis en quête d'idées !
Voici comment ça fonctionne:
- lorsque vous démarrez un nouveau job d'import, votre processus "django" créé un objet job dans la Base de Données (table 'creme_core_job'), puis averti le manager via la FIFO configurée (Redis ou socket Unix actuellement) qu'il faut démarrer ce nouveau job.
- le processus manager est réveillé par la FIFO, interroge la DB (pour être sûr que le job existe bien, récupérer son type...), et créé un nouveau processus fils qui va exécuter ledit job.
- dans le cas du job d'import CSV/XLS, le job va créer pour chaque ligne du fichier qui a été gérée une ligne en DB (table 'creme_core_massimportjobresult'), ce qui permet de savoir combien de lignes ont été traitées (ce qui est utile pour afficher la barre de progression ainsi que les statistiques finales) et de pouvoir éventuellement reprendre proprement un import après un crash (on évite les doublons pour les lignes déjà créées avant le crash).
- pendant ce temps dans votre browser du code JS interroge régulièrement le serveur Web pour connaître la progression du job. La vue interroger va 'pinger' le manager (via la FIFO) et récupérer les statistiques du job (pour afficher la barre de progression dans votre browser).
- Quand le job est fini, l'état du job est mis à jour en DB (la vue de progression va s'en apercevoir quand elle est interrogée), le processus du job averti le manager via la FIFO (pour que le processus soit fermé proprement).
Du coup avec ces quelques informations vous devriez pouvoir investiguer plus précisément pour trouver où se trouve le problème (parce que quand vous dites "le process reste actif mais le front n'arrive pas à la joindre" ce n'est pas très clair de quel est le process dont vous parlez par exemple). Est-ce que le processus du job est toujours actif ? Si oui continue-t-il de créer des lignes dans 'creme_core_massimportjobresult' ? etc...
En espérant qu'on arrivera à trouver les éventuels bug dans trop de souci.
Bonne continuation !
Bonjour,
Merci pour ce retour détaillé.
Pour les imports nous avons trouvé la solution.
Je ne connaissais pas supervisor, je vais tenter l'aventure.
Bonne continuation
