You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jira@kafka.apache.org by "Stanislav Kozlovski (Jira)" <ji...@apache.org> on 2024/02/07 20:11:00 UTC

[jira] [Closed] (KAFKA-15651) Investigate auto commit guarantees during Consumer.assign()

     [ https://issues.apache.org/jira/browse/KAFKA-15651?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stanislav Kozlovski closed KAFKA-15651.
---------------------------------------

> Investigate auto commit guarantees during Consumer.assign()
> -----------------------------------------------------------
>
>                 Key: KAFKA-15651
>                 URL: https://issues.apache.org/jira/browse/KAFKA-15651
>             Project: Kafka
>          Issue Type: Sub-task
>          Components: clients, consumer
>            Reporter: Kirk True
>            Assignee: Kirk True
>            Priority: Major
>              Labels: consumer-threading-refactor, kip-848-preview
>             Fix For: 3.7.0
>
>
> In the {{assign()}} method implementation, both {{KafkaConsumer}} and {{PrototypeAsyncConsumer}} commit offsets asynchronously. Is this intentional? [~junrao] asks in a [recent PR review|https://github.com/apache/kafka/pull/14406/files/193af8230d0c61853d764cbbe29bca2fc6361af9#r1349023459]:
> {quote}Do we guarantee that the new owner of the unsubscribed partitions could pick up the latest committed offset?
> {quote}
> Let's confirm whether the asynchronous approach is acceptable and correct. If it is, great, let's enhance the documentation to briefly explain why. If it is not, let's correct the behavior if it's within the API semantic expectations.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)