He-Pin opened a new issue, #3385: URL: https://github.com/apache/pekko/issues/3385
### Motivation In `MessageSerializer.numberToProto`, `BigInt` and `BigDecimal` (both Scala and Java variants) currently fall through to the `NumberType.Serialized` path, which uses Java `ObjectOutputStream`. This is: 1. **Inefficient** — Java serialization produces much larger payloads than necessary (vs 4-8 bytes for primitive protobuf encoding) 2. **Security risk** — Java deserialization is a known attack surface, even with `NumberInputStream` allowlist 3. **Inconsistent** — `MetricNumericConverter.convertNumber` already truncates `BigInt → Long` and `BigDecimal → Double` for metric evaluation, proving this precision is acceptable for cluster metrics use cases (heap size, CPU load, system load average) ### Proposed Change Add explicit cases in `numberToProto` (before the `Serialized` fallback): ```scala case n: java.math.BigInteger => Number.newBuilder().setType(NumberType.Long).setValue64(n.longValue) case n: java.math.BigDecimal => Number.newBuilder().setType(NumberType.Double).setValue64(jl.Double.doubleToLongBits(n.doubleValue)) case n: BigInt => Number.newBuilder().setType(NumberType.Long).setValue64(n.longValue) case n: BigDecimal => Number.newBuilder().setType(NumberType.Double).setValue64(jl.Double.doubleToLongBits(n.doubleValue)) ``` ### Rolling Upgrade Compatibility No wire protocol breaking change: - Deserialization is driven by the `NumberType` tag, not the value type - New nodes sending `Double`/`Long` for these values → old nodes read them fine (existing `Double_VALUE`/`Long_VALUE` cases) - Old nodes sending `Serialized` → new nodes still handle via `NumberInputStream` (unchanged fallback) ### Precision Impact Negligible for cluster metrics: - `Long` covers up to 9.2 × 10¹⁸ (far beyond any heap size in bytes) - `Double` gives ~15 significant digits (far beyond any load average or percentage) ### References Related: #3382 (added java.math.BigInteger/BigDecimal support in `convertNumber`) -- 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
