[
https://issues.apache.org/jira/browse/KAFKA-17541?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17951151#comment-17951151
]
Apoorv Mittal commented on KAFKA-17541:
---------------------------------------
[~isding_l] May be KAFKA-19020 can be helpful here as well, but I am not sure
as of now. Though KAFKA-19020 will only consider the request params for
maxFetchRecords but this ticket requires a mechanism to track and acquire only
specific records when delivery count is beyond certain limit. There could be
some overlap but I think we can pick this ticket first as well and then align
the same code with maxFetchRecords strict behaviour, if possible. However if
you think this ticket is not achievable as per 4.1 timelines then please let us
know.
> Improve handling of delivery count
> ----------------------------------
>
> Key: KAFKA-17541
> URL: https://issues.apache.org/jira/browse/KAFKA-17541
> Project: Kafka
> Issue Type: Sub-task
> Reporter: Andrew Schofield
> Assignee: Lan Ding
> Priority: Major
>
> There are two situations in which the delivery count handling needs to be
> more intelligent.
> First, for records which are automatically released as a result of closing a
> share session normally, the delivery count should not be incremented. These
> records were fetched but they were not actually delivered to the client since
> the disposition of the delivery records is carried in the ShareAcknowledge
> which closes the share session. Any remaining records were not delivered,
> only fetched.
> Second, for records which have a delivery count which is more than 1 or 2,
> there is a suspicion that the records are not being delivered due to a
> problem rather than just natural retrying. The batching of these records
> should be reduced, even down to a single record as a time so we do not have
> the failure to deliver a poisoned record actually causing adjacent records to
> be considered unsuccessful and potentially reach the delivery count limit
> without proper reason.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
