[ https://issues.apache.org/jira/browse/KAFKA-5621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16100349#comment-16100349 ]
Sumant Tambe commented on KAFKA-5621: ------------------------------------- [~ijuma], [~apurva], It looks like this proposal will change the notional accumulator timeout from request.timeout.ms (r.t.m) to (r.t.m * retries). The bound on the send path of a record from the point when send returns is up to linger.ms + r.t.m * retries + retries * (r.t.m. + retry.backoff.ms). So time of the send failure notification could potentially double as two full retry cycles will be applied. I prefer an explicit name to the accumulator timeout (we proposed batch.expiry.ms) but I'm well aware that adding new configs makes things harder for the enduser. I prefer to avoid overloading configs to do multiple jobs. That's confusing too. Applying retries to accumulator is not intuitive to me. It seems to jack up accumulator time by a multiple. Having said that, if there is strong agreement over not adding a new config, I'm fine with the proposed trick here. > The producer should retry expired batches when retries are enabled > ------------------------------------------------------------------ > > Key: KAFKA-5621 > URL: https://issues.apache.org/jira/browse/KAFKA-5621 > Project: Kafka > Issue Type: Bug > Reporter: Apurva Mehta > Fix For: 1.0.0 > > > Today, when a batch is expired in the accumulator, a {{TimeoutException}} is > raised to the user. > It might be better the producer to retry the expired batch rather up to the > configured number of retries. This is more intuitive from the user's point of > view. > Further the proposed behavior makes it easier for applications like mirror > maker to provide ordering guarantees even when batches expire. Today, they > would resend the expired batch and it would get added to the back of the > queue, causing the output ordering to be different from the input ordering. -- This message was sent by Atlassian JIRA (v6.4.14#64029)