...
The changes can refer to the example PR: https://github.com/apache/kafka/pull/13320/files
Add two configures with tiny code changes related which control the timeout in KafkaProducer#send
1. Two configures added
...
Producer's configure.
...
configure item.
default value
...
includeWaitTimeOnMetadataInMaxBlockTime
...
max.block.ms.include.metadata
...
false
...
maxWaitTimeMsOnMetadata
...
max.block.metadata.ms
...
2. Code changes
By default, includeWaitTimeOnMetadataInMaxBlockTime is true, all of the behaviors are not changed.
...
If user want to use the feature, user can upgrade the client with can call the new configures setadded method.
If user don't have requirement for it, there isn't any need to do any change.
What's more, new client version's upgrade also won't influence existed behavior.
- What impact (if any) will there be on existing users?
no impact on existed users. - If we are changing behavior how will we phase out the older behavior?
no changing older behavior. - If we need special migration tools, describe them here.
no. - When will we remove the existing behavior?
no need to remove.
Test Plan
We can test with test matrix:
if we need N (2<N<5) seconds for metadata's fetch, we will send record to test producer with different configures.
...
...
max.block.ms
...
includeWaitTimeOnMetadataInMaxBlockTime(max.block.ms.include.metadata)
...
maxWaitTimeMsOnMetadata(max.block.metadata.ms)
...
1
...
10 seconds
...
default value: false
...
default value: 60 seconds
...
2
...
1 seconds
...
default value: false
...
default value: 60 seconds
...
3
...
10 seconds
...
true
...
default value: 60 seconds
...
4
...
1 seconds
...
true
...
5 seconds
...
5
...
1 seconds
...
true
...
1 seconds
Rejected Alternatives
Case 2 and case 5 will fail to send records. All of others are success.
Rejected Alternatives
Alternative 1: