[jira] [Commented] (KAFKA-10170) ReplicaManager should be responsible for checking delayed operations after appending to the log.

["Chia-Ping Tsai (Jira)" <ji...@apache.org>]

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

Chia-Ping Tsai commented on KAFKA-10170:
----------------------------------------

This is addressed by https://github.com/apache/kafka/commit/c2273adc25b2bab0a3ac95bf7844fedf2860b40b

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