[
https://issues.apache.org/jira/browse/KAFKA-10170?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chia-Ping Tsai resolved KAFKA-10170.
------------------------------------
Resolution: Duplicate
> ReplicaManager should be responsible for checking delayed operations after
> appending to the log.
> ------------------------------------------------------------------------------------------------
>
> Key: KAFKA-10170
> URL: https://issues.apache.org/jira/browse/KAFKA-10170
> Project: Kafka
> Issue Type: Improvement
> Reporter: Chia-Ping Tsai
> Assignee: Chia-Ping Tsai
> Priority: Minor
>
> This issue aims to refactor code to simplify the code of checking delayed
> operations. This issue is inspired by [~hachikuji]
> (https://github.com/apache/kafka/pull/8657#discussion_r426943627)
> {quote}
> Currently we have a somewhat convoluted model where ReplicaManager creates
> delayed operations, but we depend on lower level components like Partition to
> be aware of them and complete them. This breaks encapsulation.
> Not something we should try to complete in this PR, but as an eventual goal,
> I think we can consider trying to factor delayed operations out of Partition
> so that they can be managed by ReplicaManager exclusively. If you assume that
> is the end state, then we could drop completeDelayedRequests and let
> ReplicaManager always be responsible for checking delayed operations after
> appending to the log.
> Other than ReplicaManager, the only caller of this method is
> GroupMetadataManager which uses it during offset expiration. I think the only
> reason we do this is because we didn't want to waste purgatory space. I don't
> think that's a good enough reason to go outside the normal flow. It would be
> simpler to follow the same path. Potentially we could make the callback an
> Option so that we still have a way to avoid polluting the purgatory.
> {quote}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
