KAFKA-17616: Remove KafkaServer #18384
Conversation
| Time.SYSTEM, | ||
| threadNamePrefix = None | ||
| ) | ||
| throw new RuntimeException("ZooKeeper is not supported") |
There was a problem hiding this comment.
Can we not simply remove this class? It's not a public class and I don't think anything references it besides the relevant shell script.
There was a problem hiding this comment.
If the KafkaServer is still existent, we can't remove many unused classes/configs from code base. For example, zk configs and ZkMetadataCache. Do we have any use cases for KafkaServer in 4.0?
There was a problem hiding this comment.
I actually meant something else - I was asking whether we need to keep kafka.Kafka. The answer is yes since it is still used for KRaft. But looking at this in more detail, this exception message doesn't make sense in a world where ZK is not supported since it will throw this when process roles is empty.
We should simply remove this conditional code and leave it to KafkaConfig to throw the appropriate exception if processRoles is empty.
There was a problem hiding this comment.
Sorry for misunderstanding your comment
We should simply remove this conditional code and leave it to KafkaConfig to throw the appropriate exception if processRoles is empty.
make sense
| @@ -1068,8 +1059,7 @@ class DynamicListenerConfig(server: KafkaBroker) extends BrokerReconfigurable wi | |||
| listenersToMap(newConfig.effectiveAdvertisedBrokerListeners))) { | |||
| verifyListenerRegistrationAlterationSupported() | |||
| server match { | |||
| case kafkaServer: KafkaServer => kafkaServer.kafkaController.updateBrokerInfo(kafkaServer.createBrokerInfo) | |||
| case _ => throw new RuntimeException("Unable to handle non-kafkaServer") | |||
| case _ => throw new RuntimeException("Unable to handle reconfigure") | |||
There was a problem hiding this comment.
If we always throw this exception, we probably don't need to do verifyListenerRegistrationAlterationSupported before that and we may be able to delete that method if it's not used anywhere else.
There was a problem hiding this comment.
We should remove SocketServerConfigs.ADVERTISED_LISTENERS_CONFIG from ReconfigurableConfigs as well.
That can disallow users to configure advertised listeners dynamically.
There was a problem hiding this comment.
There's a bunch of other ZooKeeper related logic in this class so I was planning to address them together in a follow up issue. Deleting KafkaServer enables us to start removing other classes that depend on this one.
There was a problem hiding this comment.
There's a bunch of other ZooKeeper related logic in this class so I was planning to address them together in a follow up issue. Deleting KafkaServer enables us to start removing other classes that depend on this one.
I'm ok to merge this and then address comments in the follow-up, because there are many cleanup blocked by KafkaServer
There was a problem hiding this comment.
I'm ok with that, but let's file a JIRA so we don't lose track.
There was a problem hiding this comment.
I care particularly about the error messages and such things since they are not easy to find afterwards.
There was a problem hiding this comment.
I opened https://issues.apache.org/jira/browse/KAFKA-18405 with details about this issue.
| @@ -69,6 +69,8 @@ object KafkaBroker { | |||
| * you do change it, be sure to make it match that regex or the system tests will fail. | |||
| */ | |||
| val STARTED_MESSAGE = "Kafka Server started" | |||
|
|
|||
| val MIN_INCREMENTAL_FETCH_SESSION_EVICTION_MS: Long = 120000 | |||
There was a problem hiding this comment.
It's a bit odd that we're not following the Scala convention here. Since we're rewriting this stuff in Java anyway, maybe it's ok.
There was a problem hiding this comment.
+1 due to #18384 (comment)
It would be nice to get feedback from @ijuma before merging it
|
Thanks for the reviews. I pushed another commit removing a bunch of methods/classes that were only used by KafkaServer. |
Committer Checklist (excluded from commit message)