[
https://issues.apache.org/jira/browse/KAFKA-5621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16103516#comment-16103516
]
Apurva Mehta commented on KAFKA-5621:
-------------------------------------
[~sutambe] : We could name the second config {{batch.expiry.ms}}, I didn't
remember the proposed name.
I guess at this point we need to figure out which option we pick for satisfying
a good out of the box experience for applications, while making tools like
mirror maker still work optimally.
1. We have the option for reserving idempotence only for apps. So when
idempotence is disabled KMM can be tuned just the way it is today.
2. We add the {{batch.expiry.ms}}. When it is defined by the user, we disable
retries for expired batches. This will work for KMM. Applications which don't
touch this setting will have their expired batches retried.
3. ??? any other options for resolving these two use cases?
> 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)
