transport: Invoke net.Conn.SetWriteDeadline in http2_client.Close#8534
Conversation
net.Conn.SetWriteDeadline in Close
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## master #8534 +/- ##
==========================================
- Coverage 82.47% 81.24% -1.24%
==========================================
Files 413 415 +2
Lines 40513 40823 +310
==========================================
- Hits 33415 33166 -249
- Misses 5743 6101 +358
- Partials 1355 1556 +201
🚀 New features to boost your workflow:
|
arjan-bal
left a comment
There was a problem hiding this comment.
Can you please add a test to verify the fix and catch regressions? You can refer to the test for the write deadline:
grpc-go/internal/transport/transport_test.go
Lines 2946 to 3009 in b0bc6dc
net.Conn.SetWriteDeadline in Closenet.Conn.SetWriteDeadline in http2_client.Close
|
PTAL @arjan-bal |
| func (t *http2Client) Close(err error) { | ||
| t.conn.SetWriteDeadline(time.Now().Add(time.Second * 10)) | ||
| if err := t.conn.SetWriteDeadline(time.Now().Add(time.Second * 10)); err != nil { | ||
| logger.Warningf("Failed to set write deadline when closing connection: %v", err) |
There was a problem hiding this comment.
These logs are too chatty. They're appearing almost every time a connection is closed, e.g:
tlogger.go:126: WARNING http2_client.go:993 [transport] Failed to set write deadline when closing connection: set tcp 127.0.0.1:59286: use of closed network connection (t=+590.186033ms)
I don't think we should log here because we are calling conn.Close in another goroutine and expecting these calls to fail.
There was a problem hiding this comment.
Dropped the logging.
arjan-bal
left a comment
There was a problem hiding this comment.
LGTM. Adding a second reviewer.
dfawley
left a comment
There was a problem hiding this comment.
Thank you for the change. A couple small things to potentially change.
| t.conn.SetWriteDeadline(time.Now().Add(time.Second * 10)) | ||
| // For background on the deadline value chosen here, see | ||
| // https://github.com/grpc/grpc-go/issues/8425#issuecomment-3057938248 . | ||
| t.conn.SetReadDeadline(time.Now().Add(time.Second)) |
There was a problem hiding this comment.
I think it would be better/simpler to just use SetDeadline with the same 1 second deadline, if possible.
There was a problem hiding this comment.
I think it's possible to do that, but am a little concerned about throwing that in here with the other changes, only because it seems like a possible load-bearing change for which I can't really vouch myself. I took a look back at #7371, where the write deadline was added, and couldn't seem to find any direct discussion about why the value of 10 was chosen, or whether a value of 1 might be problematic.
I don't mind just flipping this to 1, but also wonder if you prefer that we not do that in this PR, and then change it later? That way if everything else is good but the change from 10 to 1 introduces some separate problem, it's a simple revert of just that one-liner PR?
Not sure how your team likes to balance risk:throughput.
There was a problem hiding this comment.
@dfawley -- I didn't realize that my comment above may not have made it to you unless I explicitly request review, so I just did that.
I can make the change to replace calls to SetReadDeadline and SetWriteDeadline with a single call to SetDeadline, but want to check in with you about the concerns ^^^ re combining both changes in the same PR.
There was a problem hiding this comment.
I'm OK either way, here. It's theoretically less risky to combine them because of the behavior change, but I'm not that concerned since the original number was picked pretty arbitrarily in the first place, and neither are expected to hit unless there is a problem with the connection.
There was a problem hiding this comment.
That should say "more risky", sorry. Let's just go with what's in this PR, then. Thank you!
| co := ConnectOptions{ | ||
| Dialer: dialer, | ||
| } | ||
| server, client, cancel := setUpWithOptions(t, 0, &ServerConfig{}, normal, co) |
There was a problem hiding this comment.
If we were to set read/write deadlines during handshaking (we currently only block on the context here, but our server does set deadlines here), then this test would be invalid. I think we should either confirm that the values are still false before calling Close, or clear them unconditionally then.
There was a problem hiding this comment.
Thanks for finding that. I clear them now unconditionally.
|
This PR is labeled as requiring an update from the reporter, and no update has been received after 6 days. If no update is provided in the next 7 days, this issue will be automatically closed. |
|
This PR is labeled as requiring an update from the reporter, and no update has been received after 6 days. If no update is provided in the next 7 days, this issue will be automatically closed. |
…grpc#8534) Fixes: grpc#8425 This PR adds a call to `net.Conn.SetWriteDeadline`, as discussed in grpc#8425 (comment). Additionally, it updates the previous call to `SetReadDeadline` to log any non-nil error value (this doesn't affect behavior but proved helpful in some earlier debugging). RELEASE NOTES: * client: Set a read deadline when closing a transport to prevent it from blocking indefinitely on a broken connection.
Fixes: #8425
This PR adds a call to
net.Conn.SetWriteDeadline, as discussed in #8425 (comment). Additionally, it updates the previous call toSetReadDeadlineto log any non-nil error value (this doesn't affect behavior but proved helpful in some earlier debugging).RELEASE NOTES: