ReCounters.java returns a counter without retries from create()
Los mantenedores suelen responder en 1 día
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 1/5
- Tiempo estimado
- Menos de una hora
- Aptitud para principiantes
- 85/100
Línea de trabajo
El cambio pertenece a create en src/main/java/co/stateful/retry/ReCounters.java, que actualmente devuelve this.origin.create(name) sin envolver. Compáralo con get, que ya envuelve su resultado en ReCounter, y envuelve el resultado de create de la misma manera. Está terminado cuando set e incrementAndGet en un contador recién creado reintentan ante IOException, igual que los contadores obtenidos con get. La descripción no nombra ningún archivo de prueba, así que revisa si ya existe una prueba de reintentos que puedas ampliar.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
ReCounters.create("hits") returns the original counter without a ReCounter wrapper. Consequently, new ReSttc(sttc).counters().create("hits").set(10L) propagates the first IOException from set, even if a second attempt would succeed. The same counter obtained through get("hits") has retry protection. This contradicts ReSttc's promise to retry requests and also affects incrementAndGet on a newly created counter.
In src/main/java/co/stateful/retry/ReCounters.java, lines 58–60:
public Counter create(final String name) throws IOException {
return this.origin.create(name);
}
The annotation on create retries creation itself; it cannot intercept later method calls on the returned original counter. get already wraps its result in ReCounter on line 79, whose set and incrementAndGet methods carry @RetryOnFailure.
Wrap the result of create in the same decorator:
public Counter create(final String name) throws IOException {
return new ReCounter(this.origin.create(name));
}
This one-line change gives counters returned by both entry points the same retry behavior.
- Lenguaje dominante
- Java
- Estrellas
- 10
- Forks
- 3
- Merge medio
- 4 h 22 min
- PR fusionados (30 d)
- 9
Preparar el entorno
Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.
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 sttc/java-sdk
-
bug
Dificultad 2/5 1-3 horas Aptitud para principiantes 82/100
sttc/java-sdk#145 · 1 comentario ·
Los mantenedores suelen responder en 1 día
-
MkCounter.name() returns the class name instead of the counter name, and MkCounters drops the namePosiblemente ocupada @yegor256 la tomó hace 9 días. Abiertobug
sttc/java-sdk#142 · 1 comentario · 1 asignado ·
Los mantenedores suelen responder en 1 día
-
Dependency DashboardAbiertowontfix
Dificultad 1/5 Menos de una hora Aptitud para principiantes 35/100
Los mantenedores suelen responder en 1 día
Todos los issues de sttc/java-sdk
Issues similares
-
Run the CLI with JBangAbiertoenhancement XS
Dificultad 2/5 1-3 horas Aptitud para principiantes 68/100
nikolas-charalambidis/facepalm-maven-plugin#237 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 62/100
Los mantenedores suelen responder en 1 día
-
bug
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
dekobon/big-code-analysis#1913 ·
Los mantenedores suelen responder en 1 día
-
bug
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
Los mantenedores suelen responder en 1 día
-
bug:unconfirmed
Dificultad 2/5 1-3 horas Aptitud para principiantes 68/100
UniversalMediaServer/UniversalMediaServer#6473 ·
Los mantenedores suelen responder en 1 día