Le mardi 08 juin 2010 à 15:24 +0200, Jean Couteau a écrit :

Le 08/06/2010 15:07, Brendan Le Ny a écrit :

...

J'ai rédigé un premier draft :

http://svn.nuiton.org/svn/diswork/trunk/src/site/rst/diswork-daemon/how_it_w...

N'hésitez pas à me remonter des incohérences ou des comportements qui pourraient poser problème.

Plusieurs remarques dans le désordre :

Pourquoi se limiter à des applis java étant donné que tu les lances depuis la ligne de commande. Potentiellement, tu peux juste avoir un ordonnanceur en java qui utilise diswork mais lance un modèle en python ou autre... (oui je sais c'est un (tout petit) peu tordu, mais à l'EC je discute pas mal et il y a des personnes qui ont des problématiques de ce genre).

Parce qu'une ligne de commande, c'est spécifique à un OS. Mettons que ma ligne de commande, ce soit /bin/echo "truc" : ça marchera pas sous Windows. On peut aussi penser aux chemins passé en paramètres de la ligne de commande. En se restreignant à des jars ("java -jar" + arguments), on est plutôt sûr que l'environnement d'exécution est correct, la seule dépendance étant la JVM. Reste le cas où, dans le code du jar, y'a des chemins codés en dur... et là, c'est hors de mon périmètre. C'est un point de vue. Je veux bien en discuter plus longement.

Sinon, pour quoi se limiter à trois échecs, ne pourrait-on pas mettre ça dans la config de diswork ?

Pas de soucis, c'était un peu sous-entendu en fait. On peut créer autant de dossier FAILED_? qu'on veut, une conf sur démon dira de ne pas essayer plus de N tentatives et du coup, n'ira pas chercher les jobs au delà de FAILED_N. Inversement, celui qui soumet le job aura une configuration comme "abandonner au bout de N tentatives", il ira supprimer le job quand il sera dans FAILED_N (si besoin, dans le sous-dossier RUNNING).

#. Sometimes, while choosing a job, check in the RUNNING directory if any symlink is not too old (use the name of the link). It may means that a node crashed while processing this job. Move it to the RUNNING directory of the next failure level (TODO → FAILED_1 → FAILED_2 → FAILED_3) and try process it.

Une idée serait peut-être de, à chaque fois que tu regardes un dossier, tu regardes le dossier running et tu fais le ménage dedans, et sinon, comment tu définis la fréquence de ton sometimes ?

Accessoirement, comment tu définis le répertoire dans lequel tu vas chercher tes jobs ? Aléatoire ? Tu commences par les plus vieux (failed_3) ? Les plus jeunes (todo) ?

Justement, j'ai laisser l'ambiguïté, dans le sens où il ne serait pas gênant que les nœuds se comportent différemment. Si on veut fixer le comportement, parcourir les dossiers en sens inverse en privilégiant les running échoués me paraît une bonne solution. Dans chaque dossier, on privilégie le plus vieux histoire de faire du FIFO. Merci pour tes réflexions, Brendan.