apache / apache/rocketmq

[Enhancement] Avoid unnecessary allocation in Message.getProperty and NFE in getPriority

Open Beginner friendly
#10,464 2 comments 0 reactions 0 assignees View on GitHub
Dominant language
Java
Stars
22.6k
Forks
12k
Avg merge
3d 1h
Merged PRs (30d)
27

Description

### Before Creating the Enhancement Request

- [x] I have confirmed that this should be classified as an enhancement rather than a bug/feature.

### Summary

Avoid unnecessary allocation in `Message.getProperty` and `NumberFormatException` in `getPriority`.

### Motivation

JFR profiling on the broker send path reveals two per-message allocation issues in `Message.java`:

1. **`getProperty(String)`** — when `properties == null` (common for freshly constructed messages before tags/keys are set), the current code creates a `new HashMap<>()` as a side-effect of a read-only call, then immediately discards it. This adds ~one empty HashMap allocation per send on the producer side.

2. **`getPriority()`** — delegates to `NumberUtils.toInt(getProperty(PROPERTY_PRIORITY), -1)`. When PRIORITY is unset (the vast majority of messages), `getProperty` returns `null`, and `NumberUtils.toInt(null, ...)` internally calls `Integer.parseInt(null)` which throws and catches a `NumberFormatException` on every invocation. JFR `jdk.JavaExceptionThrow` shows ~16,000 NFE/min from this path.

### Describe the Solution You'd Like

- `getProperty()`: return `null` immediately when `properties == null` instead of creating an empty HashMap.
- `getPriority()`: add a null/empty fast-path before calling `NumberUtils.toInt()` to skip the NFE throw+catch.

### Describe Alternatives You've Considered

- Keep current behavior and accept the allocation overhead — not acceptable under high-throughput load.
- Use `Optional` wrapping — adds more allocation, not better.

### Additional Context

JFR `jdk.JavaExceptionThrow` shows ~16,000 NFE/min from the `getPriority` path under benchmark load.

Contributor guide

Open the contributing guide

Research direction

Start in Message.java at getProperty(String) and getPriority(), the two entry points identified in the issue. Inspect their current handling of unset properties, then verify that reads no longer allocate an empty map and that an unset priority avoids the NumberFormatException path while preserving the existing priority behavior.

Written by the indexing model from the issue text.

Assessment

Tech stack
java
Domain
backend, performance
Issue type
Feature
Difficulty
2/5
Estimated time
1-3 hours
Activity status
Quiet
Clarity
Clearly specified
Newbie friendliness
72/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.