-
Notifications
You must be signed in to change notification settings - Fork 420
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
Allow clients to shutdown gracefully #1308
Conversation
Motivation: If users wish to shutdown their client after all running RPCs have completed then it is currently up to them to monitor when all of their running RPCs have completed. This is somewhat awkward and we should provide a better way to do this. Modifications: - Two new requirements on the `GRPCChannel` protocol which have default implementations to avoid breaking API: - `closeGracefully(deadline:promise:)`, and - `close(promise:)` (the future-based version already exists) - The internal `ConnectionManager` has been updated to shutdown with a 'mode', either forceful or graceful and accept a promise. - The semantics of shutdown in the connecting and active states has changed slightly to complete when the `closeFuture` is resolved. This required ignoring SSL unclean shutdown errors (which can safely be ignored for gRPC). - The idle handler state machine was also altered to only send GOAWAY frames when the client closes and there are no open streams. If there are open streams the layers above (i.e. `ConnectionManager` and `ChannelPool`) will not request new streams. Results: A `GRPCChannel` may be shutdown gracefully, allowing existing RPCs to run to completion.
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.
This is a really nice patch @glbrntt: the API surface makes sense and the implementation is straightforward and clear, along with good test coverage. 10/10 good work.
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.
Thanks! This is awesome!
Motivation: If users wish to shutdown their client after all running RPCs have completed then it is currently up to them to monitor when all of their running RPCs have completed. This is somewhat awkward and we should provide a better way to do this. Modifications: - Two new requirements on the `GRPCChannel` protocol which have default implementations to avoid breaking API: - `closeGracefully(deadline:promise:)`, and - `close(promise:)` (the future-based version already exists) - The internal `ConnectionManager` has been updated to shutdown with a 'mode', either forceful or graceful and accept a promise. - The semantics of shutdown in the connecting and active states has changed slightly to complete when the `closeFuture` is resolved. This required ignoring SSL unclean shutdown errors (which can safely be ignored for gRPC). - The idle handler state machine was also altered to only send GOAWAY frames when the client closes and there are no open streams. If there are open streams the layers above (i.e. `ConnectionManager` and `ChannelPool`) will not request new streams. Results: A `GRPCChannel` may be shutdown gracefully, allowing existing RPCs to run to completion.
Motivation:
If users wish to shutdown their client after all running RPCs have
completed then it is currently up to them to monitor when all of their
running RPCs have completed. This is somewhat awkward and we should
provide a better way to do this.
Modifications:
GRPCChannel
protocol which have defaultimplementations to avoid breaking API:
closeGracefully(deadline:promise:)
, andclose(promise:)
(the future-based version already exists)ConnectionManager
has been updated to shutdown with a'mode', either forceful or graceful and accept a promise.
changed slightly to complete when the
closeFuture
is resolved.This required ignoring SSL unclean shutdown errors (which can safely
be ignored for gRPC).
frames when the client closes and there are no open streams. If there
are open streams the layers above (i.e.
ConnectionManager
andChannelPool
) will not request new streams.Results:
A
GRPCChannel
may be shutdown gracefully, allowing existing RPCs torun to completion.