[jira] [Commented] (KAFKA-15558) Determine if Timer should be used elsewhere in PrototypeAsyncConsumer.updateFetchPositions()

["Phuc Hong Tran (Jira)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/KAFKA-15558?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17800672#comment-17800672 ] 

Phuc Hong Tran commented on KAFKA-15558:
----------------------------------------

[~kirktrue], please correct me if I'm wrong, but isn't this already fixed in https://github.com/apache/kafka/pull/14912?

> Determine if Timer should be used elsewhere in PrototypeAsyncConsumer.updateFetchPositions()
> --------------------------------------------------------------------------------------------
>
>                 Key: KAFKA-15558
>                 URL: https://issues.apache.org/jira/browse/KAFKA-15558
>             Project: Kafka
>          Issue Type: Task
>          Components: clients, consumer
>            Reporter: Kirk True
>            Assignee: Phuc Hong Tran
>            Priority: Major
>              Labels: consumer-threading-refactor, kip-848-preview
>             Fix For: 3.8.0
>
>
> This is a followup ticket based on a question from [~junrao] when reviewing the [fetch request manager pull request|https://github.com/apache/kafka/pull/14406]:
> {quote}It still seems weird that we only use the timer for {{{}refreshCommittedOffsetsIfNeeded{}}}, but not for other cases where we don't have valid fetch positions. For example, if all partitions are in {{AWAIT_VALIDATION}} state, it seems that {{PrototypeAsyncConsumer.poll()}} will just go in a busy loop, which is not efficient.
> {quote}
> The goal here is to determine if we should also be propagating the Timer to the validate positions and reset positions operations.
> Note: we should also investigate if the existing {{KafkaConsumer}} implementation should be fixed, too.



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