[
https://issues.apache.org/jira/browse/KAFKA-5886?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16188552#comment-16188552
]
Tommy Becker commented on KAFKA-5886:
-------------------------------------
[~sutambe] yes that sounds great which is why I was hoping this patch would get
in ;) The write up on the KIP page was very helpful and informative. We're
struggling a bit to figure out how best to work around this issue currently
though. Obviously increasing {{request.timeout.ms}} even more is one option,
but 120000 already feels quite hight; I'm surprised that is not enough to
produce to a 3 node cluster with {{acks = all}}.
> Introduce delivery.timeout.ms producer config (KIP-91)
> ------------------------------------------------------
>
> Key: KAFKA-5886
> URL: https://issues.apache.org/jira/browse/KAFKA-5886
> Project: Kafka
> Issue Type: Improvement
> Components: producer
> Reporter: Sumant Tambe
> Assignee: Sumant Tambe
> Fix For: 1.0.0
>
>
> We propose adding a new timeout delivery.timeout.ms. The window of
> enforcement includes batching in the accumulator, retries, and the inflight
> segments of the batch. With this config, the user has a guaranteed upper
> bound on when a record will either get sent, fail or expire from the point
> when send returns. In other words we no longer overload request.timeout.ms to
> act as a weak proxy for accumulator timeout and instead introduce an explicit
> timeout that users can rely on without exposing any internals of the producer
> such as the accumulator.
> See
> [KIP-91|https://cwiki.apache.org/confluence/display/KAFKA/KIP-91+Provide+Intuitive+User+Timeouts+in+The+Producer]
> for more details.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
