Should round-robin node selection take into account queued calls?
I maintainer di solito rispondono entro 1 giorno
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 5/5
- Tempo stimato
- Più di una settimana
- Idoneità per principianti
- 25/100
- Tipo di issue
- Funzionalità
- Chiarezza
- Abbastanza chiara
- Stato di attività
- Ferma
- Stack tecnologico
- java
- Ambito
- backend-api-design, networking
Direzione di ricerca
Inizia da RemotingOkHttpClient.redirectToNewRequest e analizza come accede al dispatcher e seleziona i nodi. Determina il comportamento previsto quando la coda è satura e documenta una strategia concordata per la selezione dei nodi; il lavoro è completato quando è stato deciso un design e ne è stato validato l’effetto sulle chiamate distribuite su più nodi.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
OKHttp defines a maximum number of concurrent calls per host. This is currently set to 64. If I have a multi-node service where one of the nodes is performing poorly, I can run into a situation where - even with round-robin as my node selection strategy - I end up making calls to a node that become queued up, even if those calls could have been dispatched to other nodes much more quickly.
I've seen instances of this where at any given time I'll have 64 running threads for calls to one node (with hundreds queued up) and only single-digit threads for calls to other nodes. RemotingOkHttpClient.redirectToNewRequest would be able to take into account the queue (since it has access to the dispatcher) - what do you think of supplying a new node selection strategy that takes that queue saturation into account?
- Lingua principale
- Java
- Stelle
- 96
- Fork
- 95
- Merge medio
- 8m
- PR unite (30g)
- 55
Preparare l'ambiente
- Nessun Dockerfile né file Docker Compose
- Ha un modello di pull request
- Nessuna guida per i contributori
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 palantir/conjure-java-runtime
-
Difficoltà 4/5 3-5 giorni Idoneità per principianti 48/100
palantir/conjure-java-runtime#3585 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 3/5 1-2 giorni Idoneità per principianti 50/100
palantir/conjure-java-runtime#3166 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 5/5 Più di una settimana Idoneità per principianti 35/100
palantir/conjure-java-runtime#2490 · 3 reazioni ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 3/5 1-2 giorni Idoneità per principianti 45/100
palantir/conjure-java-runtime#2248 · 2 commenti ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 5/5 Più di una settimana Idoneità per principianti 35/100
palantir/conjure-java-runtime#2131 · 1 commento ·
I maintainer di solito rispondono entro 1 giorno
Tutte le issue di palantir/conjure-java-runtime
Issue simili
-
status:pending type:bug
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
EngineHub/WorldGuard#2329 ·
I maintainer di solito rispondono entro 3 giorni
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 70/100
Dans-Plugins/Medieval-Roleplay-Engine#396 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
I maintainer di solito rispondono entro 6 giorni
-
type: dependency-upgrade
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 70/100
spring-projects/spring-session#4156 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 68/100
quarkiverse/quarkus-langchain4j#3127 · 1 commento ·
I maintainer di solito rispondono entro 1 giorno