[Enhancement] Eliminate per-RPC allocation from Logback status, TopicMessageType toLowerCase, and RemotingHelper eager evaluation

[wang-jiahua]

Before Creating the Enhancement Request

• I have confirmed that this should be classified as an enhancement rather than a bug/feature.

Summary

Three independent per-RPC/per-metrics micro-allocations can be eliminated to reduce unnecessary heap pressure:

1. Logback BasicStatusManager — internal status events accumulate during XML configuration loading without being consumed.
2. TopicMessageType.getMetricsValue() — allocates a new String on every call via value.toLowerCase().
3. RemotingHelper.getRequestCodeDesc() / getResponseCodeDesc() — eagerly evaluates String.valueOf(code) in Map.getOrDefault() even on cache hit.

Motivation

JFR settings=profile on a broker under steady-state send load reveals these three allocation sites as recurring per-RPC waste:

• Logback status events (InfoStatus, BodyEvent) accumulate in BasicStatusManager retained set (~655 KiB) despite never being queried in production. Adding NopStatusListener suppresses the callback overhead.
• TopicMessageType.getMetricsValue() is called once per send for metrics labeling. The toLowerCase() result is deterministic per enum constant — caching it in the constructor avoids ~1 String + 1 byte[] per RPC.
• RemotingHelper.getRequestCodeDesc() and getResponseCodeDesc() are called per RPC response. Java eagerly evaluates String.valueOf(code) as a method argument to Map.getOrDefault(), allocating a String even when the key exists in the map. A simple get() + null check eliminates this on the hot (cache-hit) path.

Combined, these save ~200–300 bytes per RPC with zero behavioral change.

Describe the Solution Youd Like

1. Logback: Add <statusListener class="ch.qos.logback.core.status.NopStatusListener"/> after <configuration> in rmq.broker.logback.xml.

2. TopicMessageType: Cache metricsValue as a final String field initialized in the enum constructor with Locale.ROOT. The getter returns the cached reference directly.

3. RemotingHelper: Replace REQUEST_CODE_MAP.getOrDefault(code, String.valueOf(code)) with:

   String desc = REQUEST_CODE_MAP.get(code);
   return desc != null ? desc : String.valueOf(code);

   Same pattern for RESPONSE_CODE_MAP.

Describe Alternatives Youve Considered

• Removing NopStatusListener: Considered using a conditional listener or loggerContext.getStatusManager().clear() in code. Rejected because the XML-level listener is simpler and doesnt require broker startup changes.
• String.intern() for metrics values: Rejected due to global String table contention and lack of locale control.
• computeIfAbsent for RemotingHelper: Overkill — the map is a static Map<Integer, String> populated at class load time. A null check is simpler and avoids lambda allocation.

Additional Context

PR: #10491

This PR is stacked on PR #10443 (AttributeKey statics) and will be rebased on develop after #10443 merges to show only the 3 files above.

[RockteMQ-AI]

Issue Evaluation

Category: type/enhancement | Status: Evaluated

Feasibility: Feasible
Scope: broker/metrics, remoting/netty, common/message
Compatibility: No breaking changes — purely internal optimization.

Well-identified micro-allocations. The three fixes are independent and low-risk:

1. Logback NopStatusListener — standard practice for embedded Logback.
2. TopicMessageType.getMetricsValue() caching — deterministic per enum, trivially cacheable.
3. RemotingHelper lazy evaluation — avoids unnecessary String.format() on hot paths.

These are good first-contribution candidates. Each can be a separate small PR.

---

Automated evaluation by RockteMQ-AI

[RockteMQ-AI]

Issue Evaluation

Category: type/enhancement | Status: Evaluated

Feasibility: Feasible
Scope: rmq.broker.logback.xml, TopicMessageType, RemotingHelper
Compatibility: No breaking changes.

Three independent micro-optimizations, all well-motivated by JFR profiling:

1. NopStatusListener — Trivial config change, ~655 KiB saved. No downside.
2. TopicMessageType.getMetricsValue() caching — Standard enum constant caching pattern. Use Locale.ROOT for toLowerCase() as proposed.
3. RemotingHelper eager evaluation — Map.get() + null check instead of getOrDefault() with eager String.valueOf(). Classic hot-path optimization.

Combined ~200-300 bytes/RPC saved with zero behavioral change. Clean, low-risk PR.

---

Automated evaluation by RockteMQ-AI

[RockteMQ-AI]

Issue Evaluation

Category: type/enhancement | Status: Evaluated

Three per-RPC allocation eliminations:

1. Logback BasicStatusManager — Valid. Adding NopStatusListener suppresses internal status event accumulation (~655 KiB retained) that is never queried in production.
2. TopicMessageType.getMetricsValue() toLowerCase caching — Valid. Cache the lowercased value in the enum constructor to avoid per-call String allocation.
3. RemotingHelper lazy evaluation — Valid. Map.getOrDefault(key, String.valueOf(code)) eagerly evaluates the default; switching to computeIfAbsent or explicit containsKey avoids the allocation on cache hit.

Note: PR #10491 appears to be associated with this issue.

Feasibility: Feasible. Each change is isolated and low-risk.
Scope: broker/remoting modules
Compatibility: No breaking changes.

---

Automated evaluation by RockteMQ-AI