[GH] (rocketmq/perf/metrics-attributes-cache): Workflow run "Build and Run Tests by Maven" is working again!

[GitBox <gi...@apache.org>]

The GitHub Actions job "Build and Run Tests by Maven" on rocketmq.git/perf/metrics-attributes-cache has succeeded.
Run started by GitHub user wang-jiahua (triggered by wang-jiahua).

Head commit for run:
3dfbe3aee737f4af0d100d48c78d0a1f4dc7191f / wangjiahua.wjh <wa...@alibaba-inc.com>
[ISSUE #10481] Cache OTel Attributes objects in broker/remoting metrics hot path

Builds on top of PR #10443 (which introduces the typed AttributeKey constants).

After AttributeKey instances are de-duplicated, the next allocation hot
spot in the metrics path is the Attributes object itself. For repeated
parameter combinations the broker keeps rebuilding identical immutable
Attributes (each ~200-300 byte). This commit introduces a two-level
cache (volatile inline cache + ConcurrentHashMap fallback) at three
points:

- BrokerMetricsManager.getOrBuildTopicAttributes(topic, msgType, isSystem):
  4-field volatile inline cache + CHM keyed by 'topic|msgType|isSystem'.

- RemotingMetricsManager.getOrBuildAttributes(reqCode, respCode, isLongPolling, result):
  long-packed cache key (35 bits across 4 args, no String allocation),
  volatile inline cache + CHM. Falls back to direct build for unknown
  result values.

- RemotingCodeDistributionHandler: replace two independent volatile fields
  (lastCode, lastAdder) with an immutable CachedCounter holder published
  through a single volatile reference. A single volatile read per inc()
  returns a self-consistent (code, adder) snapshot, eliminating a
  torn-read between the two fields under @Sharable concurrent access
  from multiple Netty EventLoop threads.

Report URL: https://github.com/apache/rocketmq/actions/runs/27405267630

With regards,
GitHub Actions via GitBox