Refactoring to onStreamOpen, onStreamClose, and onStreamCloseWithError to include Node
Chưa có ai nhận issue này.
Đánh giá
- Độ khó
- 4/5
- Thời gian dự kiến
- 3-5 ngày
- Mức phù hợp với người mới
- 35/100
- Loại issue
- Tái cấu trúc
- Độ rõ ràng
- Khá rõ ràng
- Mức độ hoạt động
- Đình trệ
- Công nghệ
- grpc, java
- Lĩnh vực
- backend-api-design
Hướng nghiên cứu
Bắt đầu với vòng đời của stream observer và đọc phần thảo luận của pull request được liên kết, đặc biệt là các đánh đổi về thời điểm onStreamOpen được kích hoạt. Theo dõi cách DiscoveryRequest cuối cùng cung cấp Node cho onStreamClose và onStreamCloseWithError. Được xem là hoàn tất khi các callback cung cấp Node ở nơi có sẵn, các callback đóng tài liệu hóa Node nullable, và thời điểm được chọn cho sự kiện mở nhất quán với giao thức ADS/xDS.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
Relevant discussion: https://github.com/envoyproxy/java-control-plane/pull/35#discussion_r177099465
Ideally we would have access to the Node during the stream open and close callbacks. Due to the stream observer design, there are some tradeoffs in order to support that.
For onStreamOpen, currently we're triggering that callback outside of the request StreamObserver. At that point, we haven't actually received a DiscoveryRequest yet, so we haven't been given the Node yet. A potential workaround would be to delay the onStreamOpen event until we receive the first request message. In theory there could be an arbitrarily large gap between when the stream is actually opened and when the first request is sent and with this approach we lose the ability to measure that. In practice, is that something that we really care about for this use case? With the ADS/xDS protocol design, the first message is always sent from the client and it occurs immediately after the stream is opened.
For onStreamClose and onStreamCloseWithError, we can just cache the Node from the last request message. Consumers will just need to be aware that the node parameter in this scenario is @Nullable because the stream could close without ever receiving a request.
- Ngôn ngữ chính
- Java
- Star
- 312
- Fork
- 150
- Chỉ số merge pull request
- Không có pull request nào được merge trong 30 ngày
Hướng dẫn đóng góp
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- 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.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của envoyproxy/java-control-plane
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 45/100
envoyproxy/java-control-plane#481 ·
-
Support stream scoped routes Đang mở
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 30/100
envoyproxy/java-control-plane#471 · 1 bình luận ·
-
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 45/100
envoyproxy/java-control-plane#463 ·
-
help Đang mở
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 25/100
envoyproxy/java-control-plane#432 ·
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 45/100
envoyproxy/java-control-plane#411 ·
Tất cả issue của envoyproxy/java-control-plane
Issue tương tự
-
documentation
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 65/100
inu-appcenter/memorIN-backend#288 ·
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 65/100
-
frontend maui-pilot pilot-ask question
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 75/100
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 75/100
-
executions.Query — startDate and timeRange filters are sent with inverted comparison operators Đang mởarea/plugin
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 75/100
kestra-io/plugin-kestra#190 ·