Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

Support stream-level rebalancing for long-running RPCs (MaxStreamAge)

Abierto
  • ¿Algo no está bien?
#12,575 6 comentarios 0 reacciones 0 asignados Ver en GitHub

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
35/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Tranquilo
Stack tecnológico
grpc, java
Área
backend-api-design, distributed-systems

Línea de trabajo

Comienza con la propuesta A9 de gestión de conexiones en el lado del servidor y las referencias de grpc-go a keepalive.go e internal/transport/http2_server.go. Después, revisa el ciclo de vida de los streams y los puntos de entrada del manejo de errores de grpc-java, que no se mencionan en el issue. Se considera terminado cuando exista un diseño gRFC aceptado que cubra el jitter, el estado de terminación, el comportamiento de reintento y la paridad de funcionalidades para grpc-java y grpc-go.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

enhancement
Is your feature request related to a problem?

At our scale (1000+ client streams across 150 servers), long-running streaming RPCs (VStream CDC, Pub/Sub, Bigtable watch) create a load balancing problem with ORCA metrics. Using MaxConnectionAge causes connection churn for idle streams that only receive ORCA metrics. We need per-stream lifecycle management for efficient L7 load balancing.

The problem is that each server or client gRPC stream must implement its own stream termination logic in order to effectively use ORCA metrics and L7 load balancing. See best practices mentioned in https://github.com/grpc/grpc-java/issues/12525#issuecomment-3564341605.

Describe the solution you'd like

Similar to server-side connection management (gRPC A9) with MaxConnectionAge & MaxConnectionGrace for L4 load balancers, we propose adding a MaxStreamAge. Note we intentionally do not add grace since MaxConnectionGrace can be used to terminate with a graceful and forceful signal, while vstream is terminated the same either way (with error).

  • terminate a stream after the given age (with jitter to avoid thundering herd)
  • work at L7 (stream level) instead of L4 (connection level)
  • allow orca metrics to continue flowing on the connection
  • send an error code that clients could handle and immediately retry on the connection (possibly connecting to another server based on gRPC metrics)

This would prevent every application from re-implementing the same interval/jitter/status logic for long-running streams.

Describe alternatives you've considered
  • MaxConnectionAge: Inefficient with L7 LB; closes connection even for idle ORCA streams
  • Client-side timers: Every client must implement jitter/retry logic differently
  • Server-side timers: Requires custom code per service (repeated development effort); no standard status codes
  • MaxConnectionIdle: Only triggers when ALL streams are idle, not per-stream
Additional context

Our production environment uses:

  • Server: grpc-go (Vitess vttablet)
  • Client: grpc-java (application clients)

We need feature parity in both implementations for this to work. We're willing to implement both and contribute the code if the design is accepted. If we gain support on this issue, we can work on a gRFC as this would likely benefit from formal design review.

Lenguaje dominante
Java
Estrellas
12.1k
Forks
4k
Merge medio
2 d 3 h
PR fusionados (30 d)
30

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de grpc/grpc-java

Todos los issues de grpc/grpc-java

Issues similares

Más issues de Java

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.