Hello folks, there is a long standing issue about calculating an accurate backlog in presence of batch messages [1]. Now that we have PIP-105, broker side filters, the problem becomes bigger.
I have sent a patch [2] to provide a feature to "analise" a Subscription and scan the non dispatched messages to perform an accurate calculation: - count the number of "logical" messages, considering batch messages - execute the EntryFilter The suggested usage of this feature will be: - use stats/metrics to monitor the backlog - if the backlog is bigger than expected use the new command to understand what's happening Thoughts ? Best regards Enrico [1] https://github.com/apache/pulsar/issues/10705 [2] https://github.com/apache/pulsar/pull/16545
