-
Notifications
You must be signed in to change notification settings - Fork 280
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
Service.close #32
Comments
I've been thinking a bunch about the issue of graceful shutdown. I know that finagle includes it as part of its abstraction, but I'm not sure it makes sense to include as part of Tower. Specifically, I would imagine that graceful shutdown would happen directly with the server. I would think that the server implementation would take some sort of future that completes when the server should start to gracefully shut down. When the future resolves, the server would then drop the service handle. Service values can implement a drop handle if they need to hook into close and perform some cleanup. Do you think there is something else that I am missing? |
sorry, it's hard to link everything together here. I guess a little example would help. E.g. how can one construct a chain of services with NewService, yet provide the linking between server and some inner service in the chain to let server know when shutdown is complete. |
Well, let me turn it back on you and ask for a concrete example illustrating what you are trying to achieve :) |
A specific case I have in mind is the following:
Bridging the gap between the signal handler and the server may just be a simple Oneshot -- but I'd expect tower servers (and clients, even) to be able to instrument the rest of this shutdown logic... Ideally, specifically for tower-h2, this would do the right thing by issuing GOAWAY frames to clients. |
Right, so given this example, the SIGTERM signal is a separate concept to handling the request / response exchange, it doesn't seem like it makes sense for I'm even not sure how much it makes sense to handle at the tower-h2 level because that lib doesn't manage accepting connections. Off the top of my head, At the hyper level where the library handles accepting sockets, I would expect that you pass in a shutdown future when starting the server that completes when the SIGTERM happens, then the shutdown logic starts. |
The shutdown process is roughly something like:
|
I believe that this is out of scope. I do think there is a need to figure out graceful shutdown, but I don't think the answer will involve changes to the |
Are there plans to support graceful termination of services? E.g. in Finagle Close() method returning Future is a core part of the Service class.
The text was updated successfully, but these errors were encountered: