Closed abe-winter closed 4 months ago
Thank you for your effort but graceful exit with immediate second stage doesn't look like graceful exit, it is just exit :)
I tried to implement graceful exit without GOAWAY
frame in #190. Here the first stage is more aggressive, should exit predictably and as soon as possible. And the only way to reach the second stage should be some slow cancellation logic inside a method handler.
In this implementation when graceful exit begins server starts to reject incoming requests on existing connections using REFUSED_STREAM error code while connection is not completely drained.
Can you install grpclib
from graceful-exit
branch and check if it works for you?
Thank you very much for looking at this.
I tried your graceful-exit
branch as well as a few other versions (current master, 0.4.6, 0.4.7).
It looks like our specific shutdown issue was fixed between 0.4.6 and 0.4.7.
Looked deeper: removing server.py L739 causes 0.4.7 to behave like 0.4.6
(removing await _server_closed_fut in Server.wait_closed)
I should have tested on the latest release before submitting a fix -- I'm sorry about that.
Do you want me to do any more investigation? Or should I close this because it only affects an old version.
closing, guessing not needed
What changed
_single_stage
kwarg ingraceful_exit
which runsfirst_
andsecond_stage
in sequence, rather than waiting for a second signalWhy
We use grpclib in a scenario where https://github.com/vmagamedov/grpclib/issues/107 is a problem. We currently workaround by SIGTERM-ing twice. I'm hoping to add this kwarg so that we can trigger more aggressive shutdown behavior.