nextflow-io/nextflow

Ability to use a time delay in 'errorStrategy' to re-submit scheduler jobs

Open

#721 ouverte le 30 mai 2018

Voir sur GitHub
 (17 commentaires) (0 réactions) (0 assignés)Groovy (784 forks)batch import
help wanted

Métriques du dépôt

Stars
 (3 382 stars)
Métriques de merge PR
 (Merge moyen 16j 9h) (54 PRs mergées en 30 j)

Description

Our HPC system is giving large amounts of errors like this:

Error executing process > 'sambamba_dedup_flagstat (1)'

Caused by:
  Failed to submit process to grid scheduler for execution

Command executed:

  qsub -terse .command.run

Command exit status:
  1

Command output:
  Unable to run job: failed receiving gdi request response for mid=1 (got syncron message receive timeout error)..
  Exiting.

This is the result of the scheduler (SGE) being unable to submit jobs or respond to queries. If I try again later, for example after 5 minutes, the job may be successfully scheduled.

The errorStrategy described here shows how to increase resource allotment on error.

However, in this case I need to wait a minute or two before attempt to submit the job again.

Is it possible to accomplish this or get this feature in Nextflow? An 'errorStrategy' of 'retry in 5 minutes'.

Guide contributeur

Direction de recherche
Examinez l'implémentation existante de errorStrategy dans le code de gestion des processus de Nextflow, en particulier la logique de réessai. Identifiez où un délai temporel peut être introduit. Passez en revue le code de l'exécuteur SGE pour comprendre le flux de réessai de soumission des travaux. Modifiez la configuration de errorStrategy pour accepter un paramètre temporel et implémentez un délai avant le réessai.
Stack technique
groovy
Domaine
backend
Type d'issue
Fonctionnalité
DifficultéDifficulté estimée pour un nouveau contributeur, de 1 pour un très petit changement à 5 pour un travail expert.
3
Temps estiméFourchette de temps approximative pour investiguer, implémenter, tester et préparer une pull request.
Une demi journée
Statut d'activitéDisponibilité apparente de l'issue : fraîche, active, ancienne, bloquée ou en attente d'un mainteneur.
Active
ClartéClarté avec laquelle l'issue explique le changement attendu, les critères d'acceptation et la prochaine étape.
Claire
Prérequis
GroovyGit
Accessibilité débutantScore de 1 à 100 estimant l'accessibilité de cette issue pour un premier contributeur.
60