-
Notifications
You must be signed in to change notification settings - Fork 10
Add CloseableConnection capability
#94
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
Open
gjcairo
wants to merge
9
commits into
main
Choose a base branch
from
closeable-connection-followup
base: main
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Open
Changes from all commits
Commits
Show all changes
9 commits
Select commit
Hold shift + click to select a range
2d04886
Add CloseableConnection capability
gjcairo 20ae64a
Rename requestEndReceived in HTTPKeepAliveHandler to requestBodyInFlight
gjcairo 7423a02
Tidy up flushes in HTTPKeepAliveHandler
gjcairo b5e9b54
PR nits
gjcairo d0688c1
Handle signalClose correctly in HTTPKeepAliveHandler
gjcairo c50651a
Improve test
gjcairo 67beca1
Improve docs
gjcairo b03f406
Add missing test timeout
gjcairo 585a93a
Remove reader var shadowing
gjcairo File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.
I find the semantics a bit weird that this only closes after the response is send. Why doesn't it close right away?
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.
For H1, closing after the response is sent allows users to write back a response that will contain the
Connection:closeheader, because we'll set it when signalling close.For H2, I think it's weird to just abruptly close the connection because there can be other streams open. We currently send GOAWAY but I suppose we could send
RST_STREAMs instead?I think just abruptly closing the connection feels too harsh, but perhaps that's the desired behaviour.
cc @ehaydenr
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.
I think you want to be able to do both. If you're shutting down, you may first want to send a graceful GOAWAY to avoid disrupting in flights requests. After some grace period, you may follow up with a more abrupt GOAWAY followed by connection close which would break streams. Alternatively, you may want to immediately close things abruptly if the peer is behaving badly.
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.
You think it would make sense to be able to initiate both from here, or would you have separate capabilities?
I've not given this much thought but one thing that kinda bothers me is that force closing doesn't stop you from still attempting to read or write within this handler, and that will cause errors. Basically the only thing you can do after a force close is to return. The only way I can think of doing this is by having the force close consume the reader and response sender/writer, but I don't think that's particularly nice either.
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.
I think if you force close and then do a read or write, it should probably result in an error and that's OK
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.
@ehaydenr do you wanna be able to do both the graceful shutdown and the force closure from a stream? I am actually wondering if we are doing this the wrong way around. In my opinion, having this as a stream capability is really weird and it would be better served as API on Connection. So what I am suggesting is that
Connectiongains methods fortriggerGracefulShutdown,closeand maybe a combined one that triggers graceful shutdown and after a duration closes. You can then inject anMPSCchannel into your stream handlers that will do this on the connection. What do you think about this?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.
I want to be able to do it from a request hander. Whether it's exposed as a RequestContext capability or I need to plumb it through to where I instantiate my request handler, I don't think it matters. Exposing as a capability seems like the natural way to accomplish this. What about it do you find weird?
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.
I continue to think it is weird to expose connection lifecycle management methods on request context. I feel like we will end up with a god request that will allow you to do everything with the connection. I much prefer clear separation of concerns between the request handler and the mostly read-only context of the connect and a separate connection lifecycle API. If users want to tie the two together they can setup a communication channel between those.