fix(http1): http1 server graceful shutdown fix #3233
Conversation
fix issue in the graceful shutdown logic which causes the connection future to hang when graceful shutdown is called prior to any requests being made. This fix checks to see if the connection is still in its initial state when disable_keep_alive is called, and starts the shutdown process if it is. This addresses issue hyperium#2730
|
I'm not sure if this is the best solution or not, it feels like it's catering a little too much to this one edge case if you know what I mean. But it does pass all the tests. Let me know if there's a better way to do this. |
|
Actually, it seems like the tests failed on mac-OS. I think this solution may introduce a race condition. |
|
Ok, after taking a look: the problem is that the connection is closing on all platforms, but macOS is triggering an error trying to write the second half of the request. @sfackler in your mind, what behavior did you expect? If the request has already started, as in we've received some of the bytes, but not the full headers, should that be allowed to continue? Or should that be closed, and we only allow requests to continue if they are streaming their body? I think the goal was to prevent pre-emptive idle connections from keeping the server alive, not to interrupt new connections that had their headers split between packets, right? |
|
Fixed this up in #3261. |
|
Yeah, I would expect that the idle timer would start counting as soon as the connection is created, and stop as soon as the first byte of the headers are received. The header timeout should handle the second case I think. |
fix issue in the graceful shutdown logic
which causes the connection future to hang
when graceful shutdown is called prior to any
requests being made. This fix checks to see
if the connection is still in its initial state
when disable_keep_alive is called, and starts the
shutdown process if it is.
This addresses issue #2730