BewareMyPower commented on PR #24596: URL: https://github.com/apache/pulsar/pull/24596#issuecomment-3153125921
Actually the original analysis includes that point, but it's too long that I didn't include it. However, back to the issue, users should not configure a short interval like 1s and it's impossible because it can only be configured by `messageExpiryCheckIntervalInMinutes`, whose time unit is minute. Even with the smallest config (1 minute), could `scheduleAtFixedRate` be an actual issue? If so, it means `BrokerService#checkMessageExpiry` could take more than 1 minute, which is crazy. Instead of switching to `scheduleWithFixedDelay`, we should investigate why it could take so long. If it cannot be optimized, it should not be fixed at Pulsar side. In this case, it should be an operation issue that should be fixed by: - Increase the CPU (since it means there are a lot of topics to be served) - Increase the `messageExpiryCheckIntervalInMinutes` config (to avoid frequent time consuming operation) P.S. From the screenshot, message expiry check is scheduled every 5 minutes, which is a default value. It also shows no queued tasks being executed immediately. `scheduleWithFixedDelay` might be able to avoid queuing scheduled tasks in extreme cases, but from all existing info I can see, it does not solve an actual issue. -- 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]
