Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

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

Đang mở
  • Có gì không ổn?
#12,575 6 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

Chưa có ai nhận issue này.

Đánh giá

Độ khó
5/5
Thời gian dự kiến
Hơn một tuần
Mức phù hợp với người mới
35/100
Loại issue
Tính năng
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Ít trao đổi
Công nghệ
grpc, java
Lĩnh vực
backend-api-design, distributed-systems

Hướng nghiên cứu

Bắt đầu với đề xuất A9 về quản lý kết nối phía máy chủ và các tham chiếu của grpc-go đến keepalive.go và internal/transport/http2_server.go. Sau đó, xem xét vòng đời stream và các điểm đầu vào xử lý lỗi của grpc-java, những nội dung không được nêu tên trong issue. Công việc được xem là hoàn tất khi có một thiết kế gRFC được chấp thuận, bao quát jitter, trạng thái chấm dứt, hành vi retry và tính tương đương về tính năng cho grpc-java và grpc-go.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

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.

Ngôn ngữ chính
Java
Star
12.1k
Fork
4k
Merge trung bình
2 ngày 1 giờ
Pull request đã merge (30 ngày)
31

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của grpc/grpc-java

Tất cả issue của grpc/grpc-java

Issue tương tự

Thêm issue về Java

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.