lhotari opened a new issue, #25083: URL: https://github.com/apache/pulsar/issues/25083
### Search before reporting - [x] I searched in the [issues](https://github.com/apache/pulsar/issues) and found nothing similar. ### Motivation For `pulsar-admin topics analyze-backlog`, there are broker side configurable maximum limits how many entries will be read and how long the scanning can take. `subscriptionBacklogScanMaxTimeMs` (default 2 minutes) and `subscriptionBacklogScanMaxEntries` (default 10000) control this behavior. https://github.com/apache/pulsar/blob/3efc174f42de22523c51608858aef581b8743509/pulsar-broker-common/src/main/java/org/apache/pulsar/broker/ServiceConfiguration.java#L783-L792 Increasing these settings is possible. However, it's possible that the HTTP request times out (also idle timeout in NAT/firewall etc.) before the command completes so increasing the limits might not be useful beyond a few minutes. ### Solution There should be client-side looping which calls the [`analyzeSubscriptionBacklog` API](https://pulsar.apache.org/api/admin/4.1.x/org/apache/pulsar/client/admin/Topics.html#analyzeSubscriptionBacklog(java.lang.String,java.lang.String,java.util.Optional)) with the starting point to where the previous result left off. Final results should be aggregated on client side. ### Alternatives _No response_ ### Anything else? _No response_ ### Are you willing to submit a PR? - [ ] I'm willing to submit a PR! -- 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]
