-
Notifications
You must be signed in to change notification settings - Fork 1.9k
fix: anchor Net.ReadTimeout deadline to request send time #3672
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
base: main
Are you sure you want to change the base?
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -51,8 +51,17 @@ type Config struct { | |
| // All three of the below configurations are similar to the | ||
| // `socket.timeout.ms` setting in JVM kafka. All of them default | ||
|
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This PR definitely improves semantics of the The consumer configs describe
So it seems like saying these are "similar" is possibly a little misleading and I wonder if we shouldn't make it more similar. For example, making the deadline for Fetch include the Given the significantly different times different requests might be expected to take, a single max duration of any request (which is what this becomes) possibly isn't the most useful configuration and perhaps we can do better?
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I did have an old branch somewhere that introduced a “holdTime” to the protocol interface and responseReceiver set the connection read deadline to Net.ReadTimeout + holdTime where holdTime was the appropriate field from each, i.e., FetchRequest (MaxWaitTime), ProduceRequest (Timeout), JoinGroupRequest (RebalanceTimeout), and the admin requests all had their existing Timeout field (CreateTopics, DeleteTopics, CreatePartitions, DeleteRecords, ElectLeaders, Alter/ListPartitionReassignments etc.). I don’t think I ever got around to pushing it up anyway as I wasn’t fully convinced by it |
||
| // to 30 seconds. | ||
| DialTimeout time.Duration // How long to wait for the initial connection. | ||
| ReadTimeout time.Duration // How long to wait for a response. | ||
| DialTimeout time.Duration // How long to wait for the initial connection. | ||
|
|
||
| // ReadTimeout is the maximum duration the broker will wait for a | ||
| // complete response after a request has been fully sent. The deadline | ||
| // is set once when the request is sent and applies to the entire | ||
| // response read (header + body). It must therefore be set to at least | ||
| // the longest server-side operation you expect, such as | ||
| // Consumer.Group.Rebalance.Timeout, or reads will time out before the | ||
| // broker has finished processing. | ||
| ReadTimeout time.Duration | ||
|
|
||
| WriteTimeout time.Duration // How long to wait for a transmit. | ||
|
|
||
| // ResolveCanonicalBootstrapServers turns each bootstrap broker address | ||
|
|
||
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’m going to suggest that we set this off in its own paragraph (or in the
headerparagraph above), this will make it more clear that this deadline is used beyond just passing it into the following call…Otherwise, we would want to just use the
promise.requestTime.Add(b.conf.Net.ReadTimeout)directly, rather than assigning through a temporary variable. Having it on its own paragraph gives some sort of semantic clue that the value is going to be used for more than just the one following line.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.
Good call — added a blank line below so deadline sits in its own paragraph, making it clear it spans both reads.