Support stream-level rebalancing for long-running RPCs (MaxStreamAge)
维护者通常 1 天内回复
还没有人认领这个 Issue。
评估
- 难度
- 5/5
- 预计耗时
- 一周以上
- 新手友好度
- 35/100
- Issue 类型
- 功能
- 描述清晰度
- 基本清楚
- 活跃度
- 冷清
- 技术栈
- grpc, java
调研方向
从 A9 服务端连接管理提案以及 grpc-go 对 keepalive.go 和 internal/transport/http2_server.go 的引用开始。然后检查 grpc-java 的流生命周期和错误处理入口，这些内容在 issue 中没有点名。完成意味着有一份获接受的 gRFC 设计，涵盖 grpc-java 和 grpc-go 的抖动、终止状态、重试行为和功能对等性。
由索引模型根据 Issue 内容生成。
描述
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.
- 主要语言
- Java
- 星标
- 12.1k
- 派生
- 4k
- 平均合并
- 2 天 3 小时
- 30 天内合并 PR
- 30
环境准备
从这里开始
- 先读完整个 Issue，再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库，在一个分支上完成修改。
- 提交 Pull Request，并在描述里引用这个 Issue 编号。
grpc/grpc-java 的其他 Issue
-
enhancement
难度 2/5 1-3 小时 新手友好度 88/100
grpc/grpc-java#13063 · 1 条评论 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 78/100
grpc/grpc-java#13052 · 4 条评论 ·
维护者通常 1 天内回复
-
docs enhancement
难度 2/5 1-3 小时 新手友好度 72/100
grpc/grpc-java#10824 · 8 条评论 ·
维护者通常 1 天内回复
-
难度 4/5 3-5 天 新手友好度 70/100
维护者通常 1 天内回复
-
难度 3/5 1-2 天 新手友好度 65/100
维护者通常 1 天内回复
相似的 Issue
-
bug
难度 2/5 1-3 小时 新手友好度 78/100
-
component/zeebe kind/bug
难度 1/5 1 小时以内 新手友好度 90/100
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 78/100
UniversalMediaServer/UniversalMediaServer#6356 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 88/100
refinedmods/refinedstorage2#1414 · 1 条评论 ·
-
难度 1/5 1-3 小时 新手友好度 88/100
yegor256/rultor-image#76 · 1 条评论 ·