[ 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)