[GitHub] [kafka] mumrah commented on a change in pull request #10887: MINOR: Refactor the MetadataCache interface

[GitBox <gi...@apache.org>]

mumrah commented on a change in pull request #10887:
URL: https://github.com/apache/kafka/pull/10887#discussion_r660902180



##########
File path: core/src/main/scala/kafka/server/MetadataCache.scala
##########
@@ -62,17 +46,22 @@ trait MetadataCache {
 
   def getAllTopics(): collection.Set[String]
 
-  def getAllPartitions(): collection.Set[TopicPartition]
+  def getTopicPartitions(topicName: String): collection.Set[TopicPartition]
 
-  def getNonExistingTopics(topics: collection.Set[String]): collection.Set[String]
+  def hasAliveBroker(brokerId: Int): Boolean
 
-  def getAliveBroker(brokerId: Int): Option[MetadataBroker]
+  def getAliveBrokers(): Iterable[BrokerMetadata]
 
-  def getAliveBrokers: collection.Seq[MetadataBroker]
+  def getAliveBrokerNode(brokerId: Int, listenerName: String): Option[Node]
+
+  def getAliveBrokerNodes(listenerName: String): Iterable[Node]
 
   def getPartitionInfo(topic: String, partitionId: Int): Option[UpdateMetadataRequestData.UpdateMetadataPartitionState]
 
-  def numPartitions(topic: String): Option[Int]
+  /**
+   * Return the number of partitions in the given topic, or 0 if the given topic does not exist.
+   */
+  def numPartitions(topic: String): Int

Review comment:
       I agree that the Option rather than a special value is better here. It's not a big deal either way for the current code since there aren't many usages, but in the future a new caller will have to know to check for `0`. Seems like it could be easy to introduce bugs.
   
   A longer term solution (beyond the scope of this PR) could be to have individual container objects for the topic-level metadata. This way we could easily encapsulate the "does this topic even exist" with an Option on the metadata cache. E.g., `metadataCache.topic("foo").map(_.numPartitions)`




-- 
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-unsubscribe@kafka.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org