-
Notifications
You must be signed in to change notification settings - Fork 315
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add requestProgress function to Watch and Watcher interfaces #957
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change | ||||
---|---|---|---|---|---|---|
@@ -1,5 +1,5 @@ | ||||||
// | ||||||
// Copyright 2016-2020 The jetcd authors | ||||||
// Copyright 2016-2021 The jetcd authors | ||||||
// | ||||||
// Licensed under the Apache License, Version 2.0 (the "License"); | ||||||
// you may not use this file except in compliance with the License. | ||||||
|
@@ -53,6 +53,13 @@ service KV { | |||||
} | ||||||
|
||||||
service Watch { | ||||||
// Progress requests that a watch stream progress status | ||||||
// be sent in the watch response stream as soon as possible. | ||||||
// For watch progress responses, the header.revision indicates progress. All future events | ||||||
// received in this stream are guaranteed to have a higher revision number than the | ||||||
// header.revision number. | ||||||
rpc Progress(WatchProgressRequest) returns (WatchResponse) {} | ||||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Suggested change
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Not sure if improvement There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I'll leave this for the maintainers to decide. I was following what looked like the proto pattern for RPCs in the file There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I'd go with |
||||||
|
||||||
// Watch watches for events happening or that have happened. Both input and output | ||||||
// are streams; the input stream is for creating and canceling watchers and the output | ||||||
// stream sends events. One watch RPC can watch on multiple key ranges, streaming events | ||||||
|
@@ -175,6 +182,9 @@ message ResponseHeader { | |||||
// member_id is the ID of the member which sent the response. | ||||||
uint64 member_id = 2; | ||||||
// revision is the key-value store revision when the request was applied. | ||||||
// For watch progress responses, the header.revision indicates progress. All future events | ||||||
// recieved in this stream are guaranteed to have a higher revision number than the | ||||||
// header.revision number. | ||||||
int64 revision = 3; | ||||||
// raft_term is the raft term when the request was applied. | ||||||
uint64 raft_term = 4; | ||||||
|
@@ -458,6 +468,7 @@ message WatchRequest { | |||||
oneof request_union { | ||||||
WatchCreateRequest create_request = 1; | ||||||
WatchCancelRequest cancel_request = 2; | ||||||
WatchProgressRequest progress_request = 3; | ||||||
} | ||||||
} | ||||||
|
||||||
|
@@ -497,6 +508,11 @@ message WatchCancelRequest { | |||||
int64 watch_id = 1; | ||||||
} | ||||||
|
||||||
// Requests a watch stream progress status be sent in the | ||||||
// watch response stream as soon as possible. | ||||||
message WatchProgressRequest { | ||||||
} | ||||||
|
||||||
message WatchResponse { | ||||||
ResponseHeader header = 1; | ||||||
// watch_id is the ID of the watcher that corresponds to the response. | ||||||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Alternatively we can send a single RequestProgress update at this point (we'd need to add a FutureStub property if we go this route) and we can propagate the response to all watchers.
This'll save the etcd server from getting hit with multiple requests if there are multiple watchers