[Enhancement] Avoid unnecessary allocation in Message.getProperty and NFE in getPriority
- 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
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