Should round-robin node selection take into account queued calls?
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
- 25/100
- Tipo de issue
- Nueva funcionalidad
- Claridad
- Bastante claro
- Estado de actividad
- Estancado
- Stack tecnológico
- java
- Área
- backend-api-design, networking
Línea de trabajo
Comienza con RemotingOkHttpClient.redirectToNewRequest e inspecciona cómo accede al dispatcher y selecciona los nodos. Determina el comportamiento previsto cuando la cola alcanza su capacidad y documenta una estrategia acordada de selección de nodos; se considerará terminado cuando exista un diseño decidido y se haya validado su efecto en las llamadas a través de varios nodos.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
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?
- 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
-
Support duration based retriesAbierto
Dificultad 5/5 Más de una semana Aptitud para principiantes 35/100
palantir/conjure-java-runtime#2490 · 3 reacciones ·
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
Todos los issues de palantir/conjure-java-runtime
Issues similares
-
status:pending type:bug
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
EngineHub/WorldGuard#2329 ·
Los mantenedores suelen responder en 3 días
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 70/100
Dans-Plugins/Medieval-Roleplay-Engine#396 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
Los mantenedores suelen responder en 6 días
-
Update spring-security to 7.1.3Abiertotype: dependency-upgrade
Dificultad 1/5 Menos de una hora Aptitud para principiantes 70/100
spring-projects/spring-session#4156 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 68/100
quarkiverse/quarkus-langchain4j#3127 · 1 comentario ·
Los mantenedores suelen responder en 1 día