Graceful error handling in future_lapply
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 5/5
- Tiempo estimado
- Más de una semana
- Aptitud para principiantes
- 25/100
- Tipo de issue
- Nueva funcionalidad
- Claridad
- Bastante claro
- Estado de actividad
- Estancado
- Stack tecnológico
- r
- Área
- distributed-systems
Línea de trabajo
Comience por la llamada a future_lapply y la ruta values(fs) descrita en el informe, y siga luego cómo se gestiona FutureError cuando falla la conexión con un nodo del clúster. Done debe definirse como un comportamiento claro para los nodos individuales que fallen, conservando los resultados de los nodos que completen la operación; el comportamiento debe documentarse o exponerse mediante la interfaz de gestión de errores solicitada.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
I've been using future_lapply to submit jobs to a cluster of gcloud compute nodes - which is awesome!! Thanks so much for adding this user-friendly function.
One issue I'm running into, however, concerns the behavior when one of my gcloud compute nodes goes down unexpectedly.
Here's what I see:
Error in unserialize(node$con) :
Failed to retrieve the value of ClusterFuture from cluster node #1 (on ‘35.190.151.35’). The reason reported was ‘error reading from connection’
Calls: future_lapply ... FutureRegistry -> collectValues -> value -> value.ClusterFuture
Execution halted
Is there a good way to catch these errors for individual nodes, so that I can still access results from the nodes which are still executing? IE, can we pass an on.error function to call to values(fs)?
For now I have wrapped these in a call to withCallingHandlers() to catch & ignore this error. I haven't tested it in a real-life situation, but assuming it works this may be something to include in your vignette Common Issues with Solutions.
The code currently looks like something the following:
withCallingHandlers({
remote_jobs <- future_lapply(seq_len(num_data_sims),
execute_simtest,
future.seed = 0xBEEF,
future.scheduling = 2
)
}, FutureError = function(e) NULL
)
- Lenguaje dominante
- R
- Estrellas
- 219
- Forks
- 20
- Métricas de merge de PR
- Sin PR fusionados en 30 d
Preparar el entorno
- Sin Dockerfile ni archivo de Docker Compose
- Sin plantilla de pull request
- Leer la guía de contribución
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de futureverse/future.apply
-
Dificultad 4/5 3-5 días Aptitud para principiantes 35/100
futureverse/future.apply#129 · 2 comentarios ·
-
Dificultad 4/5 3-5 días Aptitud para principiantes 40/100
futureverse/future.apply#128 · 1 comentario ·
-
Dificultad 4/5 3-5 días Aptitud para principiantes 35/100
futureverse/future.apply#112 · 3 comentarios ·
-
bug
Dificultad 4/5 3-5 días Aptitud para principiantes 35/100
futureverse/future.apply#108 · 3 comentarios ·
-
feature request
Dificultad 3/5 1-2 días Aptitud para principiantes 42/100
futureverse/future.apply#101 · 4 comentarios ·
Todos los issues de futureverse/future.apply
Issues similares
-
bug
Dificultad 1/5 Menos de una hora Aptitud para principiantes 92/100
REditorSupport/vscode-R#1883 ·
Los mantenedores suelen responder en 1 día
-
enhancement
Dificultad 2/5 1-3 horas Aptitud para principiantes 68/100
-
bug documentation
Dificultad 2/5 1-3 horas Aptitud para principiantes 65/100
r-lib/rig#483 · 1 comentario ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 68/100
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 76/100