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)