Hi Yonny, Thank you for your proposal. I have a few questions regarding the behavior when a persistent-related throttle is triggered:
For MaxPersistentFanout and MaxPersistentFanoutBytes — will the system drop entire messages, or will it drop only some recipients to stay within the limit? From the proposal, it seems to drop recipients. Could you clarify what policy will be applied? For MaxGroupFanout — if this throttle is triggered, will the system drop newly subscribed recipients, or is there a different expected behavior? Since these settings are hot-reloadable, is it possible to estimate appropriate values based on the cluster size? Best regards, Gu Jiawei (Joe) 原始邮件 发件人:Yonny Hao <popd...@gmail.com> 发件时间:2025年8月13日 17:20 收件人:dev <dev@bifromq.apache.org> 主题:[Discuss] BIP-002 Runtime Settings for Limiting Fanout Scale toPersistent Sessions Hello all, I’d like to start a discussion on *BIP-002: Runtime Settings for Limiting Fanout Scale to Persistent Sessions( * https://cwiki.apache.org/confluence/display/BIFROMQ/BIP-002%3A+Runtime+Settings+for+Limiting+Fanout+Scale+to+Persistent+Sessions *)*. This feature helps operators better control persistent-session fanout in multi-tenant scenarios, preventing *DistService* and *InboxService* hotspots caused by large persistent subscriber sets or many shared-subscription groups with persistent members. The proposal introduces three *tenant-level, runtime-configurable* settings: - *MaxPersistentFanout* – caps the number of persistent sessions per message. - *MaxPersistentFanoutBytes* – caps the total bytes fanned out to persistent sessions per message. - *MaxGroupFanout* – caps the number of shared-subscription groups per topic. I’ve started the implementation in my forked branch: https://github.com/popduke/bifromq/tree/feat-max-persistent-fanout-limit Looking forward to your thoughts and suggestions. Best regards, -- Yonny(Yu) Hao