Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
add timeout for closing connections at the graceful shutdown #1108
Both the current behavior and what this PR suggests are within what the RFC permits, i think.
Maybe we need a config knob? One downside of the current behavior is that a never ending download might pin an H2O instance forever. Having the connection close makes server stops more predictable in terms of timing.
Thank you for the PR.
Even after the second GOAWAY, some responses might still be in-flight (the specification discuss the possibility of losing requests, not responses).
In such case, it would be desirable to postpone closing the connection until those responses finish. Otherwise, the clients would be left with partial responses, and since they are partial, they would never get retried.
So if this is an issue, I would suggest adding a timer that starts after sending the second GOAWAY and wait until then, or, add a function to server-starter (assuming that you use it to control H2O) that sends SIGKILL when the server fails to stop after some time after SIGTERM has been delivered.
@deweerdt Thank you for the update!
The PR looks good to me; the only thing I'm a bit worried is that just waiting for one second might not be enough (for example for servers serving large files). Could we make it a configuration variable?
Thank you for the update. I'm glad to see the CI passing now.
Re-reading the PR, I have one concern. Please let me know what you think.