THIS IS A TEST INSTANCE. ALL YOUR CHANGES WILL BE LOST!!!!
...
The "timer" for each batch starts "ticking" at the creation of the batch. Batches expire in order when max.in.flight.request.per.connection==1. An inflight in-flight batch expire when delivery.timeout.ms has passed since the batch creation irrespective of whether the batch is in flight or not.
Public Interfaces
- This only adds a new producer configuration:
delivery.timeout.ms.
Compatibility, Deprecation, and Migration Plan
However, the producer waits the full request.timeout.ms for the in-flight request. This implies that user might be notified of batch expiry while a batch is still in-flight.
Public Interfaces
- This only adds a new producer configuration:
delivery.timeout.ms.
Compatibility, Deprecation, and Migration Plan
- Default value of retries will be changed to MAX_INT. Setting an explicit value of retries other than MAX_INT is deprecated. Use delivery.timeout.ms instead. If retries is set to a low value, exhaustion of retries for a request will not cause the contained batches to fail if delivery.timeout.ms has not passed. In effect retries config is ignoredretries – current meaning.
- request.timeout.ms – current meaning, but messages are not expired after this time. I.e., request.timeout.ms is no longer relevant for batch expiry.
- Default value of delivery.timeout.ms = 30 120 seconds
Validation
This configuration is backwards compatible. Report WARN log messages for various combinations of Throw ConfigException for timeouts that don't make sense. (E.g., delivery.timeout.ms
< linger.ms + request.timeout.ms + retry.backoff.ms)....