You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@pulsar.apache.org by "void-ptr974 (via GitHub)" <gi...@apache.org> on 2026/10/01 11:44:31 UTC

[I] [improve][broker] Improve topic watcher notification dispatch scalability [pulsar]

void-ptr974 opened a new issue, #26802:
URL: https://github.com/apache/pulsar/issues/26802

   ### Search before reporting
   
   - [x] I searched the existing issues and did not find one tracking this specific optimization.
   
   ### Motivation
   
   Broker-side topic list watchers support pattern subscriptions. In the current implementation, `TopicResources.handleNotification` iterates over the registered topic listeners and matches each listener's namespace pattern against the metadata notification path.
   
   As a result, a topic creation or deletion in one namespace also involves listener-matching work for watchers associated with other namespaces. This path may become more expensive when a broker has many watchers spread across namespaces, especially during bursts of topic creation and deletion.
   
   ### Possible improvement
   
   It would be useful to evaluate how notification dispatch scales with the number and distribution of watchers, and explore opportunities to reduce unnecessary work while preserving listener lifecycle and notification behavior.
   
   The implementation approach is open for discussion.
   
   ### Code reference
   
   [TopicResources.handleNotification on the reviewed master revision](https://github.com/apache/pulsar/blob/f175a6c1804ac87dba1bee35638eabd07778c453/pulsar-broker-common/src/main/java/org/apache/pulsar/broker/resources/TopicResources.java#L110-L138)
   


-- 
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: commits-unsubscribe@pulsar.apache.org.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


Re: [I] [improve][broker] Improve topic watcher notification dispatch scalability [pulsar]

Posted by "void-ptr974 (via GitHub)" <gi...@apache.org>.
void-ptr974 commented on issue #26802:
URL: https://github.com/apache/pulsar/issues/26802#issuecomment-6293184145

   Hi @Asthenia0412, thanks for the detailed write-up!
   
   Unfortunately this issue already has an in-flight PR: @BackendArchitectX opened #26969 on Oct 17 with essentially the same design (namespace-indexed listeners, dispatching `Created`/`Deleted` events only to listeners of the affected namespace), and it has already been reviewed and approved by @codelipenghui. So I'd consider this issue taken for now.
   
   That said, the checkpoints you listed — duplicate/legacy registration semantics, register/remove vs. notification races, the null-namespace fallback for the deprecated `BiConsumer` API, and benchmark distributions across namespaces — are exactly the right things to scrutinize on that PR. Review comments there would be a genuinely welcome contribution.
   
   ---
   
   (下面用中文补充几点,抛砖引玉)
   
   关于怎么找和评估下一个贡献方向,我自己一般这么看:
   
   **认领前先查重。** 提方案之前先通读 issue 的全部评论,并确认有没有关联 PR(GitHub 搜索框直接搜 issue 号,比如 `26802`,或者看 issue 右侧的 Development 区块)。这个 issue 其实 10 月 17 日就已经有人认领并在当天开了 PR。确定没人做之后,再尽早评论认领、开 WIP PR 关联到 issue 上,既占住坑位,也方便别人看到进展。
   
   **找题目的几个入口:**
   - 标签:`good first issue`、`help wanted`、`type/flaky-tests`(复现并修复 flaky test 很锻炼调试功力,maintainer 也非常欢迎这类贡献)
   - dev@pulsar.apache.org 邮件列表和 Slack:很多方向会先在邮件列表里讨论,比 issue 更早能看出 maintainer 的关注点
   - `pip/` 目录里的 PIP:正在推进中的设计讨论,可以参与讨论或认领其中的实现部分
   - 长期停滞的 open PR:帮忙重新验证、更新到最新 master、补充 review
   
   **评估一个方向值不值得投入,我一般看三点:**
   1. **是否匹配自己的优势。** 你已经 landed #26919、#26888、#26765,正在做 #26932 的 JMH 优化,性能/benchmark 类的问题明显是你的强项。Pulsar 的 hot path(dispatch、ack、replication、metadata watcher 等路径)还有不少和 #26802/#26803 同类的扩展性问题,很适合顺着 #26932 的思路继续挖。
   2. **收益是否可量化、影响面是否可控。** 带 before/after 数据的性能改动在 review 中最顺畅;而动到公共 API、wire protocol 或序列化格式的改动风险高、周期长,不适合作为快速迭代的方向。
   3. **社区是否有推进意愿。** 看 issue 是谁提的(maintainer 提的通常代表有方向性)、有没有关联的 PIP、历史上类似改动的 PR 是否被接受。
   
   另外,**review 别人的 PR 也是一等贡献**。高质量的 review(尤其是带 benchmark 复现和验证的)在社区里非常稀缺,也能持续加深你对代码库的理解。
   
   期待你的下一个 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: commits-unsubscribe@pulsar.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


Re: [I] [improve][broker] Improve topic watcher notification dispatch scalability [pulsar]

Posted by "void-ptr974 (via GitHub)" <gi...@apache.org>.
void-ptr974 commented on issue #26802:
URL: https://github.com/apache/pulsar/issues/26802#issuecomment-6293254747

   Hi @Asthenia0412,
   
   This issue already has an open PR: #26969, which implements the namespace-index approach and has already been reviewed and approved, so I'd consider it covered for now.
   
   If you're looking for other areas to contribute, some places to check:
   
   - Issue labels such as `good first issue`, `help wanted`, and `type/flaky-tests`
   - The dev@pulsar.apache.org mailing list and Slack — design discussions often happen there before issues are filed
   - The `pip/` directory for in-progress proposals
   - Open PRs that haven't seen activity in a while; re-validating or reviewing them is also a useful way to contribute
   
   Before picking up an issue, it's usually worth reading through the existing comments and checking for linked PRs to avoid duplicated effort.
   


-- 
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: commits-unsubscribe@pulsar.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


Re: [I] [improve][broker] Improve topic watcher notification dispatch scalability [pulsar]

Posted by "void-ptr974 (via GitHub)" <gi...@apache.org>.
void-ptr974 commented on issue #26802:
URL: https://github.com/apache/pulsar/issues/26802#issuecomment-5930646939

   Anyone interested is welcome to propose an approach and submit a PR for this improvement. The implementation details are open for discussion.


-- 
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: commits-unsubscribe@pulsar.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


Re: [I] [improve][broker] Improve topic watcher notification dispatch scalability [pulsar]

Posted by "Asthenia0412 (via GitHub)" <gi...@apache.org>.
Asthenia0412 commented on issue #26802:
URL: https://github.com/apache/pulsar/issues/26802#issuecomment-6292859242

   Hi @void-ptr974 @lhotari — 我想接这个 #26802。
   
   ## 背景
   我目前正在做 #26932(optimize TopicListWatcher hash computation with TreeSet)解决 #26803,在 review 和 benchmark 的过程中注意到 topic watcher dispatch 这个兄弟路径也有明显的扩展性问题。两个 issue 其实是互补的:一个优化 dispatch fan-out,一个优化 per-watcher 的 hash 计算。
   
   ## 设计方案
   **核心洞察**:每个 `TopicListener` 注册时都携带一个精确的 `NamespaceName`,对应的 `namespaceNameToTopicNamePattern` 已经编码了它只监听该 namespace 的 topic。所以没有必要让一个 namespace 的 topic 变更去正则匹配所有其他 namespace 的 watcher。
   
   **具体改动**:
   1. **增加 namespace 索引层**:在 `TopicResources` 中新增 `ConcurrentHashMap<NamespaceName, Set<TopicListener>>` 作为主索引(`ConcurrentHashMap` of `ConcurrentHashMap.newKeySet()`),register/deregister 同步维护这个索引,O(1) 插入/删除。
   2. **重写 handleNotification 走索引路径**:从 notification path 解析 namespace(直接字符串 split `/` 取第二段,避免正则的第一个开销),只遍历该 namespace 下的 listeners,跳过 pattern match 的冗余(注册时已经确认 namespace 精确匹配)。
   3. **保留 BiConsumer deprecated API 兼容**:旧的 BiConsumer 注册时 namespace 可能为 null(调用方没有传),这些 listener 放到 namespace 为 null 的 bucket,dispatch 时 fallback 遍历它们。
   4. **增加 JMH benchmark**(参照 #26955 microbench 模式):覆盖 100k topics × 10 watchers/ns × 20 ns 场景,对比 baseline dispatch 时间。
   
   ## 涉及文件
   - `pulsar-broker-common/.../TopicResources.java`(主要改动)
   - `pulsar-broker-common/.../TopicListener.java`(如有必要加方法)
   - `microbench/.../TopicWatcherDispatchBenchmark.java`(新增)
   - 对应单元测试
   
   ## LOC 预估
   ~600-800 新/改代码(包括 benchmark + 测试)。
   
   ## 已有背景
   我已经在这个仓库 landed #26919(broker client resume fix)、#26888(docs)、#26765(managed-ledger partial batch ACKs),正在做 #26932(#26803 hash 优化)。风格和代码习惯保持一致。
   
   如果方向没问题,我可以在 3 天内开一个 WIP 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: commits-unsubscribe@pulsar.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


Re: [I] [improve][broker] Improve topic watcher notification dispatch scalability [pulsar]

Posted by "BackendArchitectX (via GitHub)" <gi...@apache.org>.
BackendArchitectX commented on issue #26802:
URL: https://github.com/apache/pulsar/issues/26802#issuecomment-6233480545

   Hi, I'd like to work on this improvement, subject to maintainer feedback on the approach.
   
   I propose indexing persistent-topic listeners by namespace in `TopicResources`, so `handleNotification` can parse each relevant metadata path once and dispatch Created/Deleted events only to listeners for the affected namespace. This should avoid matching unrelated watchers while preserving synchronous callback dispatch.
   
   I'd preserve listener equality, re-registration and deregistration semantics (including the deprecated `BiConsumer` API), global session-event delivery, and existing topic/path filtering behavior. Tests would cover namespace isolation and prefix collisions, encoded/system topics, duplicate and legacy registrations, concurrent register/remove/notification races, and session recovery. I'd also benchmark distributions across many namespaces and the single-namespace baseline to quantify the trade-off.
   
   Would a committer be comfortable with this direction and consider assigning #26802 to @BackendArchitectX? I'm happy to adjust the design before implementation. Thanks!


-- 
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: commits-unsubscribe@pulsar.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


Re: [I] [improve][broker] Improve topic watcher notification dispatch scalability [pulsar]

Posted by "void-ptr974 (via GitHub)" <gi...@apache.org>.
void-ptr974 commented on issue #26802:
URL: https://github.com/apache/pulsar/issues/26802#issuecomment-6293224738

   Hi @Asthenia0412, thanks for the detailed write-up!
   
   Unfortunately this issue already has an in-flight PR: @BackendArchitectX opened #26969 on Oct 17 with essentially the same design (namespace-indexed listeners, dispatching `Created`/`Deleted` events only to listeners of the affected namespace), and it has already been reviewed and approved by @codelipenghui. So I'd consider this issue taken for now.
   
   That said, the checkpoints you listed — duplicate/legacy registration semantics, register/remove vs. notification races, the null-namespace fallback for the deprecated `BiConsumer` API, and benchmark distributions across namespaces — are exactly the right things to scrutinize on that PR. Review comments there would be a genuinely welcome contribution.
   
   A few thoughts on finding and evaluating your next contribution, for what they're worth:
   
   **Check for in-flight work before claiming an issue.** Read through all the comments on the issue and check for linked PRs (search the issue number, e.g. `26802`, in the GitHub search box, or look at the Development section in the sidebar) — in this case the issue was claimed and a PR was opened on Oct 17. Once you've confirmed nobody is working on it, claim it in a comment and open a WIP PR linked to the issue early, so others can see the work in progress.
   
   **Where to look for topics:**
   - Labels: `good first issue`, `help wanted`, `type/flaky-tests` (reproducing and fixing flaky tests is a great way to build debugging skills, and maintainers highly value these contributions)
   - The dev@pulsar.apache.org mailing list and Slack: many directions get discussed there first, and you can spot maintainers' areas of interest earlier than via issues
   - The `pip/` directory: ongoing design discussions where you can participate or pick up implementation work
   - Stalled open PRs: help re-validate them, update them to latest master, or add reviews
   
   **How I usually evaluate whether a direction is worth investing in:**
   1. **Does it match your strengths?** You've already landed #26919, #26888, and #26765, and you're working on the JMH optimization in #26932 — performance/benchmark work is clearly your strong suit. There are still quite a few scalability problems of the same kind as #26802/#26803 in Pulsar's hot paths (dispatch, ack, replication, metadata watchers), which would be a natural direction to continue from #26932.
   2. **Is the benefit measurable and the blast radius contained?** Performance changes with before/after numbers tend to get the smoothest reviews; changes touching public APIs, the wire protocol, or serialized formats are higher-risk and longer-cycle, and not ideal for fast iteration.
   3. **Is the community interested in pushing it forward?** Look at who filed the issue (maintainer-filed issues usually indicate direction), whether there's an associated PIP, and whether similar PRs have been accepted historically.
   
   One more thing: **reviewing others' PRs is a first-class contribution too.** High-quality reviews — especially ones backed by benchmark reproduction and verification — are scarce and highly valued, and they steadily deepen your understanding of the codebase.
   
   Looking forward to your next 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: commits-unsubscribe@pulsar.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


Re: [I] [improve][broker] Improve topic watcher notification dispatch scalability [pulsar]

Posted by "codelipenghui (via GitHub)" <gi...@apache.org>.
codelipenghui closed issue #26802: [improve][broker] Improve topic watcher notification dispatch scalability
URL: https://github.com/apache/pulsar/issues/26802


-- 
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: commits-unsubscribe@pulsar.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org