rdhabalia commented on code in PR #18212:
URL: https://github.com/apache/pulsar/pull/18212#discussion_r1008580773
##########
pulsar-client-api/src/main/java/org/apache/pulsar/client/api/ConsumerStats.java:
##########
@@ -114,4 +114,9 @@ public interface ConsumerStats extends Serializable {
* @return
*/
Map<Long, Integer> getMsgNumInSubReceiverQueue();
+
+ /**
+ * @return stats for each partition if topic is partitioned topic
+ */
+ Map<String, ConsumerStats> getPartitionStats();
Review Comment:
yes, sure, we can have separate interface for partitioned topic with more
clear code.
However, the current implementation with combined stats-recorder and
stats-interface implementation has complicated things though they are two
separate entities (recorder can't become stats but recorder should record the
stats ). combining both entities incorrectly complicates the inheritance.
We also should still keep the Partitioned topic abstraction from user.
Producer/Consumer::getStats() should return one interface with all required API
and user doesn't have to cast based on topic type. Because
Partitioned-topic-stats are just a collection of stats so, we should have
getPartitionedTopicStats() API with in Stats interface and it should return
empty response if topic is not partitioned topic.
Atleast this will be a good start to creating the abstraction and without
having existing API changes in this PR.
I will create a separate PR with further improvement.
This PR has addressed all comments.
--
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: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
