bharanic-dev commented on a change in pull request #10008:
URL: https://github.com/apache/pulsar/pull/10008#discussion_r601594478
##########
File path:
pulsar-broker-common/src/main/java/org/apache/pulsar/broker/ServiceConfiguration.java
##########
@@ -680,6 +680,26 @@
+ " non-backlog consumers as well.")
private boolean dispatchThrottlingOnNonBacklogConsumerEnabled = false;
+ @FieldContext(
+ category = CATEGORY_POLICIES,
+ doc = "Default policy for publishing usage reports to system topic
is disabled."
+ + "This enables publishing of usage reports"
+ )
+ private boolean resourceUsagePublishToTopic = false;
+
+ @FieldContext(
+ category = CATEGORY_POLICIES,
+ doc = "Topic to publish usage reports to if
resourceUsagePublishToTopic is enabled."
+ )
+ private String resourceUsagePublishTopicName =
"non-persistent://pulsar/system/resource-usage";
Review comment:
@codelipenghui thank you for the review. Prior to writing the code in
this PR, I read through the SystemTopic/TopicPolicies implementation. My
observation was that:
- it was added to publish namespace change events to a special system topic
(created under the same namespace), so every namespace will have a special
topic created.
- there is a SystemTopicClient wrapper that was added on top of
PulsarClient(), which has methods to create reader/writer for each of the above
topics. A reader/writer is created every time there is a topic policy change.
- the topic schema is hard-coded to PulsarEvent with AVRO encoding.
The resource-usage feature differs in the following way:
- one topic at the system level, one reader, one writer.
- message schema is protobuf
- periodic task to publish usages and reader callback to process usage
messages.
I don't think we could have used SystemTopic for resource-usage without
making any changes to SystemTopic. At a minimum I would have had to change
SystemTopicClientBase implementation. In my opinion, the overlap in
functionality is not large enough to make re-factoring SystemTopic and
re-testing the SystemTopic feature worthwhile. So, I decided to write the
simple code to create a single reader and writer (which is what the PR has).
W.r.t your other comment, the topic name is internal. The config option is
exposed to the user in case the topic name conflicts with the topics that user
wants to use. The user can decide that the default is OK, in which case the
topic name gets decided by the implementation.
--
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.
For queries about this service, please contact Infrastructure at:
[email protected]
