Created on 2020-09-16 10:05:24 by Pierre-yves Chabaud. % Done: 0

Plusieurs exécutions d'amazed semblent se terminer correctement alors que le traitement de certains spectres s'est interrompu.

Lorsque l'OS tue un worker (c.a.d un bunch), le scheduler du pipeline n'est pas informé. L'ensemble des spectres du bunch qui n'aura pas été traité au moment de l’interruption par l'OS ne sera pas traité. Les raisons de l'interruption (TIMEOUT, OUT_OF_MEMORY, ...) doivent être séparées du mode d'interruption (SIGKILL, SIGTERM, ...).

Il faut également distinguer les spectres dont le traitement n'a pas "convergé" (erreur attrapée par le worker) et les spectres dont le traitement n'a pas eu lieu pour cause d'interruption par l'OS. Les symptômes étant identiques a la fin d'une exécution du pipeline (absence de l'ID du spectre dans le redshift.csv). Les erreurs attrapées par les worker sont enregistrées dans le log amazed.

Le pipeline devra être en mesure de fournir:

• La liste des spectres dont le traitement n'a pas "convergé"
• La liste des bunch qui ont été interrompu par l'OS
• La liste des spectres dont le traitement n'a pas eu lieu pour cause d'interruption
• Un moyen de relancer les traitements interrompus
• Un moyen d'agréger les résultats avant et après l'interruption