[
https://issues.apache.org/jira/browse/KAFKA-5621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16102176#comment-16102176
]
Jiangjie Qin commented on KAFKA-5621:
-------------------------------------
[~apurva] Yes, I agree that expiry ms is a new concept as it is an additional
thing users may want to think, i.e. "If I have a partition unavailable
temporarily, how long am I willing to wait for it to come back?" Arguably this
can also be derived from request timeout and retries. But the difference here
is that those two configs are primarily for other cases, and in practice we
found it is quite tricky (if possible) to get them right for the batch
expiration.
> 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)
