lkokhreidze edited a comment on pull request #10851: URL: https://github.com/apache/kafka/pull/10851#issuecomment-905514160
The general thought on the implementation. As of now, we choose concrete `StandbyTaskAssignor` implementation based on passed `AssignmentConfigs` value. Instead, an alternative approach would be to have a chained standby task assignment based on multiple implementations. For instance, when have required client tag configuration is present, we can try to assign the standby tasks based on `List.of(new ClientTagAwareStandbyTaskAssignor(), new LeastLoadedClientStandbyTaskAssignor())`. This way, `ClientTagAwareStandbyTaskAssignor` can try to distribute the standby tasks based on tags dimensions. If there are no more client tag dimensions available, and we still have `any(tasksToRemainingStandbys) > 0`, the next implementation in the chain (in this case `DefaultStandbyTaskAssignor`) will be called. With this, `DefaultStandbyTaskAssignor` can default to assigning the remaining standbys to the least loaded clients. The benefit of this approach is that, right now, `ClientTagAwareStandbyTaskAssignor` does both assignments based on available dimensions and fallback to the least loaded if there are no enough tag dimensions. Current implementa tion leads to more complex code. While with the approach above, we can clearly separate the implementations without duplication (there's no code duplication, rather "logic" duplication). For now, I've chosen to go with the simplest approach - having two independent implementations and selecting an appropriate one based on passed `AssignmentConfigs.` Still, I wanted to share this idea here, just in case. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: jira-unsubscr...@kafka.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
