ReCounters.java returns a counter without retries from create()
I maintainer di solito rispondono entro 1 giorno
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 1/5
- Tempo stimato
- Meno di un'ora
- Idoneità per principianti
- 85/100
Direzione di ricerca
La modifica va apportata in create in src/main/java/co/stateful/retry/ReCounters.java, che attualmente restituisce this.origin.create(name) senza incapsulamento. Confrontalo con get, che incapsula già il risultato in ReCounter, e incapsula il risultato di create allo stesso modo. È completato quando set e incrementAndGet su un contatore appena creato ritentano in caso di IOException, come fanno i contatori ottenuti da get. La traccia non indica alcun file di test, quindi verifica se esiste già un test per i retry da estendere.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
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.
- Lingua principale
- Java
- Stelle
- 10
- Fork
- 3
- Merge medio
- 4h 22m
- PR unite (30g)
- 9
Preparare l'ambiente
Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di sttc/java-sdk
-
bug
Difficoltà 2/5 1-3 ore Idoneità per principianti 82/100
sttc/java-sdk#145 · 1 commento ·
I maintainer di solito rispondono entro 1 giorno
-
MkCounter.name() returns the class name instead of the counter name, and MkCounters drops the nameForse già presa @yegor256 l’ha presa 9 giorni fa. Apertabug
sttc/java-sdk#142 · 1 commento · 1 assegnatario ·
I maintainer di solito rispondono entro 1 giorno
-
Dependency DashboardApertawontfix
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 35/100
I maintainer di solito rispondono entro 1 giorno
Tutte le issue di sttc/java-sdk
Issue simili
-
Run the CLI with JBangApertaenhancement XS
Difficoltà 2/5 1-3 ore Idoneità per principianti 68/100
nikolas-charalambidis/facepalm-maven-plugin#237 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 62/100
I maintainer di solito rispondono entro 1 giorno
-
bug
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
dekobon/big-code-analysis#1913 ·
I maintainer di solito rispondono entro 1 giorno
-
bug
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
I maintainer di solito rispondono entro 1 giorno
-
bug:unconfirmed
Difficoltà 2/5 1-3 ore Idoneità per principianti 68/100
UniversalMediaServer/UniversalMediaServer#6473 ·
I maintainer di solito rispondono entro 1 giorno