[jira] [Assigned] (KAFKA-12361) Change default connect producer request timeout

["Chris Egerton (Jira)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/KAFKA-12361?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Chris Egerton reassigned KAFKA-12361:
-------------------------------------

    Assignee: Chris Egerton

> Change default connect producer request timeout
> -----------------------------------------------
>
>                 Key: KAFKA-12361
>                 URL: https://issues.apache.org/jira/browse/KAFKA-12361
>             Project: Kafka
>          Issue Type: Improvement
>            Reporter: Jason Gustafson
>            Assignee: Chris Egerton
>            Priority: Major
>              Labels: connect
>
> Prior to KIP-91, which introduced delivery.timeout.ms, there was no easy way to ensure that records sent through the producer would even have the opportunity to get delivered. Records could be timed out in the accumulator if `request.timeout.ms` was reached before getting sent. Users worked around this problem by setting `request.timeout.ms=Int.MaxValue`. The downside is that this made the producer slower to discover "unclean" connection failures. Now that we have KIP-91, there shouldn't be any reason to keep this workaround. 
> One place it would be good to fix this is in connect's source tasks:
> {code}
>         // These settings will execute infinite retries on retriable exceptions. They *may* be overridden via configs passed to the worker,
>         // but this may compromise the delivery guarantees of Kafka Connect.
>         producerProps.put(ProducerConfig.REQUEST_TIMEOUT_MS_CONFIG, Integer.toString(Integer.MAX_VALUE));
> {code}
> The comment about delivery guarantees is a little vague, but I think mainly it is what was discussed above about ensuring at least once delivery. Note that none of the default configs including both request timeout and delivery timeout can avoid duplicates in all cases. For that idempotence is needed. It is worth considering separately for connect whether that should be the default.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)