RockteMQ-AI commented on issue #10982: URL: https://github.com/apache/rocketmq/issues/10982#issuecomment-5438778057
**Issue Evaluation** Category: `type/enhancement` | Status: **Evaluated** **Feasibility:** Feasible — the proposed caching approach is sound. The route data for a given topic is immutable between mutation events (broker register/unregister, topic config change), so a cached `byte[]` per topic with invalidation on mutation is a valid optimization. **Scope:** `module/namesrv` — primarily `RouteInfoManager` and `ClientRequestProcessor`. **Compatibility:** No breaking changes — the wire format remains identical; only the server-side allocation pattern changes. **Assessment:** This is a well-motivated optimization. The three non-trivial aspects you identified are real: 1. **`orderTopicConf` from KV config** — The simplest approach is to keep the KV lookup outside the cache and merge it post-cache. Since `orderTopicConf` changes are rare (admin operation), the merge cost is negligible compared to the per-request deep-copy + JSON encoding savings. 2. **Two JSON shapes** — The cache needs two variants per topic (`standard` vs `legacy fastjson`). This doubles memory but both variants can be invalidated atomically on the same mutation event. A versioned copy-on-write snapshot holding both shapes is clean. 3. **`supportActingMaster` post-processing** — This is the trickiest. If `supportActingMaster` is a cluster-wide config (not per-request), it can be part of the cache key/invalidation. If it varies per request, the cache must be bypassed for that path. **Suggested simpler angle:** A versioned copy-on-write route snapshot (atomic reference swap on mutation) would avoid the deep-copy entirely on the read path, and the JSON encoding can be cached alongside. This composes well with the two-shape requirement. The author's willingness to follow up with benchmarks is appreciated. Looking forward to the implementation. --- *Automated evaluation by github-manager* -- 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]
