cmccabe commented on code in PR #16284:
URL: https://github.com/apache/kafka/pull/16284#discussion_r1635410206
##########
metadata/src/main/java/org/apache/kafka/controller/ConfigurationControlManager.java:
##########
@@ -495,8 +496,19 @@ void deleteTopicConfigs(String name) {
configData.remove(new ConfigResource(Type.TOPIC, name));
}
- boolean uncleanLeaderElectionEnabledForTopic(String name) {
- return false; // TODO: support configuring unclean leader election.
+ /**
+ * Check if this topic has "unclean.leader.election.enable" set to true.
+ *
+ * @param topicName The topic name for the config.
+ * @return true if this topic has uncleanLeaderElection enabled
+ */
+ boolean uncleanLeaderElectionEnabledForTopic(String topicName) {
Review Comment:
While this will work for most cases, there are some cases it won't catch.
For example, let's say we create a transaction that has these records:
```
begin_transaction
ConfigRecord(ResourceType=TOPIC, ResourceName="foo",
Name="unclean.leader.election", Value="true")
PartitionChangeRecord(... sets leader for foo to -1 and ISR = [2]... )
end_transaction
```
`uncleanLeaderElectionEnabledForTopic` will return false during the
transaction since the ConfigRecord has not been applied yet.
There are two ways we could try to deal with this:
1. double down on fixing the edge-triggered method, by passing in a context
here that encapsulated pending configuration changes
2. have a periodic sweep that tries to do unclean leader elections on each
leaderless partition if possible
For approach number 2, we could make it part of the periodic leader
balancing task (which runs every 5 minutes)
--
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
