Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
Http2ConnectionHandler to allow decoupling close(..) from GOAWAY graceful close #9094
Oh! A present for me!
Minor note: I'm not 100% confident we should have the gracefulShutdownTimeoutMillis convenience in the new http2 API, or what it should look like.
The behavior of gracefulShutdownTimeoutMillis is sort of easy: you set a timer and call channel.close() when it expires.
Although to do the goaway itself really well you would send a PING after the GOAWAY and when the PING ACK arrives send out the second GOAWAY. Although that needs a configuration value for when to timeout the ping and send a second GOAWAY anyway. We have this implemented in gRPC and use a hard-coded timeout of 10 seconds. The double-goaway is described in the RFC, but using PING was not.
Of the two, the two-stage GOAWAY seems much more useful to implement in-library. Anyway, I'm rambling and it is just stuff to think about.
I made a similar comment #9094 (comment) around the same time
I also agree the
To be clear, my "minor note" was more about future direction vs holding up this PR.
I'm not too worried about gracefulShutdownTimeoutMillis. It is easy to implement wherever we need it. If it isn't implemented in the builder, that may be a reason to remove it vs add it, but meh. I'm not really worried.
Yeah. I wouldn't necessarily say "5.0", but "later" SGTM and I'm fine if it only makes it into 5.0. It might just be a utility function.