lhotari commented on code in PR #24833:
URL: https://github.com/apache/pulsar/pull/24833#discussion_r2491322763
##########
pulsar-broker/src/main/java/org/apache/pulsar/broker/service/TopicListService.java:
##########
@@ -101,6 +112,7 @@ public void accept(String topicName, NotificationType
notificationType) {
private final boolean enableSubscriptionPatternEvaluation;
private final int maxSubscriptionPatternLength;
private final ConcurrentLongHashMap<CompletableFuture<TopicListWatcher>>
watchers;
+ private final Backoff retryBackoff;
public TopicListService(PulsarService pulsar, ServerCnx connection,
Review Comment:
> @lhotari The command should not be limited, because `MultiTopicsConsumer`
and `MultiTopicsProducer` need to receive this command once the topics'
partition is changed. The regexp consumer is also relies on the command.
@poorbarcode There's perhaps some misunderstanding. Memory limiting won't
prevent this command from being executed unless it times out or the queue fills
up. It is absolutely necessary to handle also CommandWatchTopicListSuccess /
CommandWatchTopicUpdate related commands so that the broker doesn't run out of
memory and that's also explained in
[PIP-442](https://github.com/apache/pulsar/blob/master/pip/pip-442.md).
Handling CommandWatchTopicListSuccess / CommandWatchTopicUpdate related
commands with the memory limiter will help the broker remain stable regardless
of a large amount of regex consumers connecting at once. When the limit is
reached, it will queue up the requests until other requests have completed.
Does this make sense?
--
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]
