ReCounters.java returns a counter without retries from create()
Mantenedores costumam responder em até 1 dia
Ninguém assumiu esta issue ainda.
Avaliação
- Dificuldade
- 1/5
- Tempo estimado
- Menos de uma hora
- Facilidade para iniciantes
- 85/100
Direção de pesquisa
A mudança pertence a create em src/main/java/co/stateful/retry/ReCounters.java, que atualmente retorna this.origin.create(name) sem encapsular. Compare com get, que já encapsula seu resultado em ReCounter, e encapsule o resultado de create da mesma forma. Está concluído quando set e incrementAndGet em um contador recém-criado fizerem nova tentativa em IOException, como os contadores obtidos de get já fazem. A descrição não menciona nenhum arquivo de teste, então verifique se já existe um teste de nova tentativa que você possa estender.
Escrita pelo modelo de indexação a partir do texto da issue.
Descrição
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.
- Linguagem predominante
- Java
- Estrelas
- 10
- Forks
- 3
- Merge médio
- 4h 22min
- PRs com merge (30d)
- 9
Preparar o ambiente
Este projeto não oferece contêiner de desenvolvimento, Dockerfile nem guia de contribuição, então a configuração fica por sua conta: comece pelo README e veja nosso guia da primeira contribuição para os passos gerais.
Primeiros passos
- Leia a issue inteira e depois o guia de contribuição do projeto.
- Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
- Faça um fork do repositório e trabalhe em uma branch.
- Abra um pull request que referencie o número da issue.
Mais de sttc/java-sdk
-
bug
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 82/100
sttc/java-sdk#145 · 1 comentário ·
Mantenedores costumam responder em até 1 dia
-
MkCounter.name() returns the class name instead of the counter name, and MkCounters drops the nameTalvez já em andamento @yegor256 assumiu há 9 dias. Abertabug
sttc/java-sdk#142 · 1 comentário · 1 responsável ·
Mantenedores costumam responder em até 1 dia
-
Dependency DashboardAbertawontfix
Dificuldade 1/5 Menos de uma hora Facilidade para iniciantes 35/100
Mantenedores costumam responder em até 1 dia
Todas as issues de sttc/java-sdk
Issues semelhantes
-
Run the CLI with JBangAbertaenhancement XS
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 68/100
nikolas-charalambidis/facepalm-maven-plugin#237 ·
Mantenedores costumam responder em até 1 dia
-
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 62/100
Mantenedores costumam responder em até 1 dia
-
bug
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 78/100
dekobon/big-code-analysis#1913 ·
Mantenedores costumam responder em até 1 dia
-
bug
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 78/100
Mantenedores costumam responder em até 1 dia
-
bug:unconfirmed
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 68/100
UniversalMediaServer/UniversalMediaServer#6473 ·
Mantenedores costumam responder em até 1 dia