Support duration based retries
Los mantenedores suelen responder en 1 día
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 5/5
- Tiempo estimado
- Más de una semana
- Aptitud para principiantes
- 35/100
Línea de trabajo
El issue no indica archivos, pruebas ni un punto de entrada que inspeccionar. Empieza por localizar la configuración existente de backoff-duration y retry-count; después, define y prueba un comportamiento de reintento basado en la duración que se detenga después del período especificado por el cliente e informe de esa duración.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
What happened?
Retry behavior is exposed via backoff duration and number of retries. Clients can specify waiting for up to 300ms before the first retry, up to 600ms before the next retry and so on until they run out retries.
Clients should think about how long they're willing to try rather than how many times they are willing to try. For example, an interactive dashboards are willing to retry for up to 10 seconds whereas long-running pipelines are willing to retry up to 20 minutes. While we can approximate this behavior with the existing controls by tuning the backoff duration and retry count, we're tuning a distribution, not a specific duration. For example, the expected time spent retrying could be 20 minutes but if we're unlucky, the total time spent retrying could be less than 2 minutes. This leads to clients that are pathologically overly sensitive to 429s from the server.
What did you want to happen?
Support duration based retries where the client specifies how long they're willing to retry. This allows the client to express their retry contract in a consistent, easy to understand way. We still get all the benefits of employing jitter to stagger retries, but the implementation details are hidden away from the client. The client tries for 20 minutes and then gives up saying that it has tried for 20 minutes. This means a lot more than giving up saying that it has tried 10 times.
- Lenguaje dominante
- Java
- Estrellas
- 96
- Forks
- 95
- Merge medio
- 8 min
- PR fusionados (30 d)
- 55
Preparar el entorno
- Sin Dockerfile ni archivo de Docker Compose
- Tiene una plantilla de pull request
- Sin 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 palantir/conjure-java-runtime
-
Dificultad 4/5 3-5 días Aptitud para principiantes 48/100
palantir/conjure-java-runtime#3585 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 3/5 1-2 días Aptitud para principiantes 50/100
palantir/conjure-java-runtime#3166 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 3/5 1-2 días Aptitud para principiantes 45/100
palantir/conjure-java-runtime#2248 · 2 comentarios ·
Los mantenedores suelen responder en 1 día
-
Dificultad 5/5 Más de una semana Aptitud para principiantes 35/100
palantir/conjure-java-runtime#2131 · 1 comentario ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 42/100
palantir/conjure-java-runtime#1882 · 1 reacción ·
Los mantenedores suelen responder en 1 día
Todos los issues de palantir/conjure-java-runtime
Issues similares
-
bug
Dificultad 1/5 Menos de una hora Aptitud para principiantes 82/100
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 84/100
objectionary/lints#1640 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 75/100
-
Dificultad 2/5 Medio día Aptitud para principiantes 68/100
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
openhab/openhab-addons#22168 ·
Los mantenedores suelen responder en 1 día