You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jira@kafka.apache.org by "Kirk True (Jira)" <ji...@apache.org> on 2023/10/19 00:09:00 UTC

[jira] [Created] (KAFKA-15640) Refactor CompletedFetch initialization

Kirk True created KAFKA-15640:
---------------------------------

             Summary: Refactor CompletedFetch initialization
                 Key: KAFKA-15640
                 URL: https://issues.apache.org/jira/browse/KAFKA-15640
             Project: Kafka
          Issue Type: Improvement
          Components: clients, consumer
            Reporter: Kirk True
            Assignee: Kirk True


The interaction between {{{}FetchBuffer{}}}, {{{}FetchCollector{}}}, and {{CompletedFetch}} is awkward, to say the least.

Per [~junrao]'s comments: 
{quote}Currently, {{fetchBuffer.setNextInLineFetch}} and {{fetchBuffer.poll}} are separate operations and we expect the caller to call them in the right order to avoid a partition missing in FetchBuffer in the transition phase. It still leaves us with the situation that a partition could be in both completedFetches and nextInLineFetch at a particular time. It's not a problem for now, but it may be in the future. Could we make them an atomic operation? If not, could we add a comment to document the correct usage of the api and the impact on partition being duplicated in completedFetches and nextInLineFetch?
{quote}



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