Penghui Li
Penghui Li
/pulsarbot run-failure-checks
@poorbarcode Interesting. I think the expected behavior is no matter how many consumers are under a subscription. The subscription should only perform the entry read operation one by one.
> Broker can go out of memory due to many reads enqueued on the PersistentDispatcherMultipleConsumers dispatchMessagesThread @eolivelli Does it only happen when the broker has many subscriptions? For one subscription,...
/pulsarbot run-failure-checks
@TakaHiR07 It's better to have a discussion on the dev mailing list. We will change the behavior of the current implementation. Just make sure everyone is clear about what we...
/pulsarbot run-failure-checks
@Demogorgon314 It's a little confusing if the TTL can only apply to the table view that is based on the non-persistent topic. Or can it also apply to the persistent...
@Demogorgon314 LGTM
@congbobo184 I think we should provide clear information while the transaction coordinator does not enable it on the broker side. It will help users to understand the problem quickly.
I think the part of `More aggressive load balance strategy` mentioned in this proposal is resolved by https://github.com/apache/pulsar/pull/17456 For the load balance epochs. I'm not if I understand it correctly....